The next major version is now installable
SvelteKit, the application framework built on top of the Svelte compiler, has put its next major version into public preview. Thirteen preview releases shipped under the npm @next tag through July 2026, and the Svelte team's official monthly update, published August 1, describes the shape of what SvelteKit 3 will eventually become. It is not yet the default install, and there is no announced date for general availability, but developers can try it today by installing the @next dist-tag.
What actually changes for existing code
The most consequential shift for developers currently shipping SvelteKit apps is in routing. The framework's goto navigation function has been reworked: as of the 3.0.0-next.13 preview release on July 29, its old noScroll and keepFocus options were removed in favor of a single reset option, and the older pushState and replaceState functions are now deprecated in favor of a new shallow-routing approach built directly into goto via a state option. Any app that leans on the old navigation options will need to migrate before adopting the new major version, since these are breaking changes rather than additions.
A related addition is state that survives a reload: calling goto with both a state object and persistState: true keeps that state around across a full page refresh, something the old shallow-routing pattern could not do on its own.
Data fetching gets a rename with a purpose behind it. invalidateAll, the function used to force SvelteKit to re-run all of a page's load functions, is deprecated in favor of a new refreshAll. The Svelte team has not detailed the full behavioral difference in the August digest, but the rename signals the function's role is being narrowed or clarified rather than simply relabeled.
New modules for introspection and service workers
SvelteKit 3 adds a $app/manifest module that exposes runtime information about a running app: which assets are immutable, which routes exist, and which pages were prerendered at build time. That is metadata previously either unavailable at runtime or only accessible indirectly, and it is aimed at tooling and advanced routing logic that needs to make decisions based on how a given build was assembled.
Service worker support also gets consolidated: a new $app/service-worker module replaces the older $service-worker import path, and $app/paths - previously restricted to regular app code - is now importable from inside a service worker itself. That closes a gap where service worker code often needed to duplicate path logic that the rest of the app already had access to.
Error handling gets a smaller but genuinely useful fix: +error.svelte components now have their page and error props typed automatically, with no configuration required, through updates to SvelteKit's language tooling. Anyone who has written a custom error page and reached for any types to make TypeScript stop complaining will not need to do that in the new version.
What is happening outside the preview branch
Not everything new is gated behind the @next tag. On the current stable line, version 2.69.0 added a submitted property to SvelteKit's remote forms feature, letting an application react the instant a form is submitted rather than waiting for a server response to come back - useful for showing immediate loading states. The same release added a field.touched() helper aimed at building better validation user experience, so a form can distinguish a field a user has interacted with from one they have simply left blank.
Separately, version 2.70.0 relocated defineEnvVars from the main @sveltejs/kit package to a new @sveltejs/kit/env subpath - a small but breaking change for any project importing it from the old location.
The 3.0.0-next.13 release notes also list more than twenty bug fixes touching content security policy (CSP) handling, the Vite development server, HTTP header management, prerendering detection, manifest generation and form submission, which is a reasonable indicator that the preview is maturing past the experimental-and-unstable stage even without a firm release date attached.
What it means in practice
For teams maintaining a production SvelteKit app today, there is no urgency: the stable line keeps shipping its own improvements, like the remote-forms additions in 2.69.0, independent of the major-version work. The preview is worth trying in a side project or a non-critical branch specifically to catch the goto and pushState/replaceState breaking changes early, since navigation code tends to be scattered across a codebase and is easier to migrate gradually than all at once when the stable release eventually lands. Teams that rely heavily on shallow routing or custom error pages are the ones with the most concrete reason to start testing now rather than waiting.
