Svelte shrinks what the browser has to run, but a real application still needs routing, data, forms, and a path to production. SvelteKit is the [full-stack framework](https://vercel.com/i/full-stack-framework) that adds those pieces on top of the Svelte compiler, and it does that while keeping the small-bundle wins that make Svelte appealing in the first place.

This guide covers how SvelteKit works, its main features, how it compares to other meta-frameworks, and how to deploy a SvelteKit app on [Vercel](https://vercel.com/docs/frameworks/full-stack/sveltekit).

## [Copy link to heading](#what-is-sveltekit)What is SvelteKit?

SvelteKit is the full-stack framework built on top of [Svelte](https://svelte.dev/docs/svelte/overview), adding file-based routing, server-side rendering, data loading, and adapter-based deployment. The current stable major is [SvelteKit 2](https://svelte.dev/docs/kit), which pairs Svelte's compile-time component output with a Vite build pipeline for fast local development and small shipped bundles.

Because Svelte compiles markup, scoped CSS, and reactivity at build time, the JavaScript that reaches the browser is mostly application logic. SvelteKit adds the glue a real app needs: routes, data, forms, API endpoints, and a consistent path from `git push` to production.

## [Copy link to heading](#how-sveltekit-works)How SvelteKit works

SvelteKit brings together compile-time component output, a Vite-powered build, and route-level rendering controls. Those three pieces are what let a project ship a marketing page, a dashboard route, and an API handler from the same codebase with different runtime profiles.

### [Copy link to heading](#compiled-components-and-vite)Compiled components and Vite

Svelte compiles `.svelte` files to imperative DOM code, so there's no virtual DOM reconciler running in the browser. The `@sveltejs/kit/vite` plugin bridges SvelteKit's conventions into Vite, which handles Hot Module Replacement during development and produces route-scoped chunks for production.

In a production build, Vite creates optimized bundles for server code, browser code, and service workers, runs any prerendering, and hands that output to the selected adapter for the target platform. Route-level code splitting keeps each page focused on the modules it needs, so chunks load in parallel over HTTP/2.

### [Copy link to heading](#server-rendering-with-client-hydration)Server rendering with client hydration

SvelteKit renders routes on the server by default, sends the HTML to the browser, and then hydrates the page so it becomes interactive. Fetched data is serialized alongside the markup, Svelte reattaches event listeners, and a client-side router takes over for later navigation.

That default is tunable per route: setting `ssr = false` produces a client-only SPA page, `csr = false` ships zero JavaScript for a fully static response, and `prerender = true` generates HTML at build time.

### [Copy link to heading](#adapter-based-deployment)Adapter-based deployment

SvelteKit makes the deployment target an explicit build-time decision. New projects install `adapter-auto` by default, which detects the environment and selects the right adapter automatically.

On Vercel, exporting a `config` object from a route file lets individual pages run as [Vercel Functions](https://vercel.com/docs/functions) on [Fluid compute](https://vercel.com/docs/fluid-compute), so a single project can tune the runtime and region for latency-sensitive pages.

## [Copy link to heading](#key-features-of-sveltekit)Key features of SvelteKit

SvelteKit gives you a consistent set of full-stack primitives that share one rule: the filesystem defines what the app does. Files starting with `+` are framework-owned, so they're visible at a glance next to regular components and utilities.

### [Copy link to heading](#file-based-routing-and-layouts)File-based routing and layouts

The directory tree under `src/routes/` defines your URL structure. A `+page.svelte` at `src/routes/about/` becomes `/about`, and dynamic segments use brackets, so `src/routes/blog/[slug]/` becomes `/blog/:slug`.

Layouts wrap child routes by default. A `+layout.svelte` at `src/routes/settings/` wraps everything under `/settings/*`, and options exported from a layout file, like `prerender`, `ssr`, or `csr`, cascade down to every child route unless a specific page overrides them.

### [Copy link to heading](#load-functions-for-data-fetching)Load functions for data fetching

SvelteKit splits data loading into two function types. Universal load functions in `+page.js` run on the server for the initial request and in the browser for client-side navigation. Server load functions in `+page.server.js` run only on the server and have direct access to cookies, database connections, and secrets.

Both run with an enhanced `fetch` that extends the native API for SvelteKit's rendering model:

- **Same-origin shortcuts**: Requests that target a local `+server.js` handler dispatch in-process, skipping the HTTP round trip.

- **Credentialed by default**: Server-side calls inherit cookies and forwarded headers, so auth works without extra wiring.

- **Relative URLs on the server**: A load function can call `/api/items` without threading the origin through manually.

- **Inlined responses**: Results fetched during SSR are serialized into the HTML, so the client doesn't repeat the request during hydration.

These four behaviors are why most SvelteKit apps need less glue code than a project with a separately deployed frontend and backend, and they keep hydration free of duplicate network calls.

### [Copy link to heading](#form-actions-with-progressive-enhancement)Form actions with progressive enhancement

Form actions exported from `+page.server.js` let a plain HTML `<form>` element `POST` straight to the server. Because the form is a native element, core submission flows keep working without JavaScript, and the `use:enhance` directive from `$app/forms` layers on pending states, optimistic updates, and controlled resets once scripts load.

### [Copy link to heading](#api-endpoints-with-+server.js)API endpoints with `+server.js`

A `+server.js` file exports functions that match HTTP methods: `GET`, `POST`, `PATCH`, `PUT`, `DELETE`, `OPTIONS`, and `HEAD`. Each function receives a `RequestEvent` and returns a `Response`, and the `json()` helper from `@sveltejs/kit` sets content-type headers for you.

When a `+server.js` and a `+page.svelte` sit in the same directory, SvelteKit uses content negotiation. `PUT`, `PATCH`, `DELETE`, and `OPTIONS` always route to the server file, while `GET`, `POST`, and `HEAD` route based on the request's `accept` header.

### [Copy link to heading](#rendering-modes)Rendering modes

SvelteKit supports configurable rendering modes through exports on a route or layout file:

- **SSR**: Renders on the server for every request. This is the default.

- **`prerender = true`**: Generates HTML at build time for content that doesn't change per visitor.

- **`prerender = 'auto'`**: Prerenders the route but keeps it in the SSR manifest for on-demand fallback.

- **`ssr = false`**: Ships a client-only SPA page with a static shell.

- **`csr = false`**: Delivers zero JavaScript for a fully static page.

Combining `prerender = true` on the root layout with `adapter-static` turns the whole project into a static site. Routes marked `prerender = true` are generated as static HTML at build time, so they drop out of the server bundle, which keeps serverless function size and cold starts down.

## [Copy link to heading](#sveltekit-vs.-svelte)SvelteKit vs. Svelte

[Svelte](https://vercel.com/i/what-is-svelte) is the UI component compiler; SvelteKit is the application framework you build on top of it. A `.svelte` file bundles markup, a `<script>` block, and a `<style>` block, and the compiler outputs vanilla JavaScript with no virtual DOM runtime.

Svelte on its own fits reusable component libraries, embeddable widgets, or SPAs where routing is plugged in separately. Reach for SvelteKit when the project needs full-stack surface area that Svelte alone doesn't cover.

## [Copy link to heading](#sveltekit-vs.-other-meta-frameworks)SvelteKit vs. other meta-frameworks

Meta-frameworks differ less in feature checklists and more in how they handle rendering, data loading, and the packages teams end up reaching for. Here's how SvelteKit compares with the three most common alternatives teams evaluate.

### [Copy link to heading](#sveltekit-vs.-next.js)SvelteKit vs. Next.js

The core difference is the browser runtime. Svelte compiles components to DOM code at build time, while React ships a virtual DOM reconciler. [Next.js 16](https://nextjs.org/blog/next-16) stabilized Partial Prerendering through Cache Components, which lets a single route combine a prerendered shell with streamed dynamic content. SvelteKit reaches similar territory through per-route `ssr`, `csr`, and `prerender` exports, which give file-level control with a smaller surface.

React's community is larger, so developers using Next.js often find a wider pool of third-party component libraries, UI kits, and auth integrations. Developers on SvelteKit lean more on framework primitives and a sharper set of community packages.

### [Copy link to heading](#sveltekit-vs.-nuxt)SvelteKit vs. Nuxt

The most visible difference is [Nuxt](https://vercel.com/i/what-is-nuxt)'s auto-import system, which makes Vue components and composables available without explicit `import` statements. SvelteKit sticks to standard JavaScript module conventions. Nuxt also ships first-party modules covering areas like image optimization and content (authentication, by contrast, is handled by community modules), while SvelteKit provides the framework and leaves those layers to the npm registry.

### [Copy link to heading](#sveltekit-vs.-remix)SvelteKit vs. Remix

[Remix 3](https://remix.run/blog/remix-3-beta-preview), currently in beta, is a ground-up rewrite that drops React for a fork of Preact and leans hard into the web platform and TypeScript. It bundles its own core building blocks — routing, sessions, auth, forms, uploads, and server rendering — to do meaningful work with minimal dependencies. SvelteKit shares that web-platform, progressive-enhancement philosophy: both treat HTML forms as the foundation for mutations, with JavaScript enhancing the experience once it loads. The difference is where each starts — SvelteKit builds on the Svelte compiler and uses `load` functions and form `actions`, while Remix 3 owns more of its own stack rather than building on a separate UI library.

## [Copy link to heading](#when-to-use-sveltekit)When to use SvelteKit

SvelteKit fits projects where shipped bundle size matters and you want tight control over where each route runs. Compiled components mean the browser downloads application logic rather than framework runtime, which is one reason SvelteKit keeps showing up in performance-sensitive work.

Three kinds of projects fit especially well:

- **Dashboards and internal tools**: Rich interactivity, frequent data fetches, and per-route rendering control line up with SvelteKit's load functions and adapter system.

- **Customer portals and product apps**: Progressive enhancement keeps core flows working even when scripts fail, and small bundles help time-to-interactive for returning visitors.

- **Greenfield full-stack products**: Routing, data loading, form actions, and API endpoints ship together, so small teams avoid stitching a separate backend for straightforward services.

Team context still shapes the decision. Some teams should weigh hiring and migration cost against the bundle and developer-experience wins before committing: those hiring heavily across larger frontend pools, those depending on specialized third-party components such as accessible data grids, or those maintaining a large React codebase.

## [Copy link to heading](#getting-started-with-sveltekit)Getting started with SvelteKit

Creating a SvelteKit project takes a single command, and the starter gives you routing, a dev server, and a build pipeline out of the box. From there, most of the learning curve is the file conventions; once those click, the rest of the framework follows the same pattern.

### [Copy link to heading](#prerequisites-and-setup)Prerequisites and setup

The main technical prerequisite is Node.js LTS. Basic familiarity with HTML, CSS, and JavaScript helps, and TypeScript is optional.

Scaffold a new project with the official Svelte CLI:

```
npx sv create my-app
cd my-app
npm run dev
```

The interactive prompt asks about a project template, language, and optional integrations like ESLint, Vitest, and Tailwind CSS.

### [Copy link to heading](#creating-your-first-route)Creating your first route

The `src/routes/` directory defines the URL structure. Adding `+page.svelte` at `src/routes/about/` creates the `/about` route, and a sibling `+page.server.js` exports a `load` function for server-side data and `actions` for form handling.

### [Copy link to heading](#running-the-dev-server)Running the dev server

`npm run dev` starts the Vite dev server on `localhost:5173` with Hot Module Replacement, so edits show up in the browser without a full refresh. `npm run build` runs the two-stage production build, first creating optimized bundles through Vite and then running the configured adapter to produce deployment-ready output.

## [Copy link to heading](#deploy-your-sveltekit-app-on-vercel)Deploy your SvelteKit app on Vercel

Vercel auto-detects SvelteKit projects during import and configures the build without a `vercel.json`. The adapter options cover Vercel Functions, Fluid compute, and ISR, so rendering strategy stays a framework-level decision instead of a platform one.

### [Copy link to heading](#auto-detected-vercel-adapter)Auto-detected Vercel adapter

Projects using `adapter-auto` are detected and built automatically when pushed to Vercel. For long-lived production apps, Vercel recommends installing `@sveltejs/adapter-vercel` explicitly for version pinning and route-level configuration. Setting the adapter in `svelte.config.js` is the only required step for the common path.

### [Copy link to heading](#ssr-and-isr-delivery)SSR and ISR delivery

SvelteKit on Vercel supports the rendering strategies most apps need:

- [**Serverless rendering**](https://vercel.com/i/serverless-computing-use-cases): [Vercel Functions](https://vercel.com/docs/functions) handle the default SSR path for dynamic routes, running on

    [Fluid compute](https://vercel.com/docs/fluid-compute) so costs track Active CPU rather than idle wait time.

- [**Incremental Static Regeneration**](https://vercel.com/docs/incremental-static-regeneration): Pages that benefit from stale-while-revalidate caching use the adapter's

    `isr` property to set expiration, bypass tokens, and cache keys.

Each mode is configurable at the project level or per route, so a single app can mix strategies. Route-level `config` exports override project-wide defaults for that specific page.

### [Copy link to heading](#previews,-analytics,-and-domains)Previews, analytics, and domains

Every pull request gets a [preview deployment](https://vercel.com/docs/deployments/environments) with a unique URL, so teams can review changes in a production-identical environment before merging. [Vercel Analytics](https://vercel.com/docs/analytics/quickstart) plugs into SvelteKit through the `@vercel/analytics/sveltekit` package and its `injectAnalytics` function. [Speed Insights](https://vercel.com/docs/speed-insights) reports real-visitor Core Web Vitals alongside traffic data.

## [Copy link to heading](#build-your-next-full-stack-app-with-sveltekit)Build your next full-stack app with SvelteKit

SvelteKit combines Svelte's compiled components, per-route rendering control, and a clean path from one codebase to different deployment targets. Its progressive enhancement model keeps core flows working without JavaScript and faster once it loads, so the same project can serve a marketing page, a dashboard, and a customer app with the same mental model.

A SvelteKit project on Vercel picks up server rendering, preview deployments, and analytics from the first deploy. [Start a new project](https://vercel.com/new) or [browse templates](https://vercel.com/templates) to see working SvelteKit setups, and upgrade to Pro when the team needs [custom environments](https://vercel.com/docs/deployments/environments) for staging and QA.

## [Copy link to heading](#frequently-asked-questions-about-sveltekit)Frequently asked questions about SvelteKit

### [Copy link to heading](#is-sveltekit-production-ready)Is SvelteKit production-ready?

Yes. SvelteKit 2 is the current stable major, and teams ship it to production on [Vercel](https://vercel.com/docs/frameworks/full-stack/sveltekit) across dashboards, content sites, and consumer products. The framework is actively maintained and widely used.

### [Copy link to heading](#can-sveltekit-replace-my-backend)Can SvelteKit replace my backend?

Partially. SvelteKit covers API endpoints through `+server.js`, server-side form handling through actions, direct database calls from server code, and secret isolation through `$lib/server`. For long-running jobs, durable multi-step processes, or AI agents that need to pause and resume, most teams pair SvelteKit with [Vercel Functions](https://vercel.com/docs/functions) and the [Workflow SDK](https://workflow-sdk.dev/docs/getting-started/sveltekit) that powers [Vercel Workflows](https://vercel.com/docs/workflows), or reach for standalone external services.

### [Copy link to heading](#does-sveltekit-support-typescript)Does SvelteKit support TypeScript?

Yes, with built-in support. TypeScript is offered during project scaffolding, and SvelteKit auto-generates typed load functions through `$types` modules. The `$lib` and `$lib/server` aliases work with full TypeScript type safety, and deployments on [Vercel](https://vercel.com/docs/frameworks/full-stack/sveltekit) pick up the TypeScript config automatically.

### [Copy link to heading](#is-sveltekit-free-and-open-source)Is SvelteKit free and open source?

Yes. The project is MIT-licensed and hosted at [github.com/sveltejs/kit](https://github.com/sveltejs/kit). You can run SvelteKit on the [Hobby plan](https://vercel.com/pricing) at no cost while prototyping and scale to Pro or Enterprise when team features are needed.