What is SvelteKit? A guide to the full-stack Svelte framework

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 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.

Link to headingWhat is SvelteKit?

SvelteKit is the full-stack framework built on top of Svelte, adding file-based routing, server-side rendering, data loading, and adapter-based deployment. The current stable major is SvelteKit 2, 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.

Link to headingHow 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.

Link to headingCompiled 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.

Link to headingServer 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.

Link to headingAdapter-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 on Fluid compute, so a single project can tune the runtime and region for latency-sensitive pages.

Link to headingKey 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.

Link to headingFile-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.

Link to headingLoad 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.

Link to headingForm 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.

Link to headingAPI 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.

Link to headingRendering 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.

Link to headingSvelteKit vs. Svelte

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.

Link to headingSvelteKit 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.

Link to headingSvelteKit 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 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.

Link to headingSvelteKit vs. Nuxt

The most visible difference 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.

Link to headingSvelteKit vs. Remix

Remix 3, 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.

Link to headingWhen 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.

Link to headingGetting 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.

Link to headingPrerequisites 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.

Link to headingCreating 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.

Link to headingRunning 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.

Link to headingDeploy 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.

Link to headingAuto-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.

Link to headingSSR and ISR delivery

SvelteKit on Vercel supports the rendering strategies most apps need:

• Serverless rendering: Vercel Functions handle the default SSR path for dynamic routes, running on

  Fluid compute so costs track Active CPU rather than idle wait time.

• 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.

Link to headingPreviews, analytics, and domains

Every pull request gets a preview deployment with a unique URL, so teams can review changes in a production-identical environment before merging. Vercel Analytics plugs into SvelteKit through the @vercel/analytics/sveltekit package and its injectAnalytics function. Speed Insights reports real-visitor Core Web Vitals alongside traffic data.

Link to headingBuild 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 or browse templates to see working SvelteKit setups, and upgrade to Pro when the team needs custom environments for staging and QA.

Link to headingFrequently asked questions about SvelteKit

Link to headingIs SvelteKit production-ready?

Yes. SvelteKit 2 is the current stable major, and teams ship it to production on Vercel across dashboards, content sites, and consumer products. The framework is actively maintained and widely used.

Link to headingCan 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 and the Workflow SDK that powers Vercel Workflows, or reach for standalone external services.

Link to headingDoes 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 pick up the TypeScript config automatically.

Link to headingIs SvelteKit free and open source?

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