How to Tell If a Website Is Built With SvelteKit
SvelteKit is the official application framework for Svelte. Detect it via /_app/ asset paths, data-sveltekit-* link attributes and the __sveltekit_ hydration global.
SvelteKit is the official application framework for Svelte, providing routing, server-side rendering, static generation and a build pipeline on top of Svelte's compile-time component model. Detecting it relies on framework-specific signals rather than a runtime global: look for /_app/ asset paths, data-sveltekit-* link attributes, and the __sveltekit_ hydration global. This guide covers every reliable signal, why Svelte's compiler model changes how you detect it, the look-alikes to rule out, and what a SvelteKit build tells you about the team.
What is SvelteKit?
SvelteKit is to Svelte what Next.js is to React and Nuxt is to Vue: the official meta-framework that wraps the UI library with the production concerns an application needs — file-based routing, server-side rendering and static generation, data loading, and a Vite-based build pipeline. Its distinguishing trait flows from Svelte itself, which is a compiler: rather than shipping a framework runtime to the browser, Svelte compiles components into small, efficient vanilla JavaScript at build time. That makes SvelteKit sites notably lightweight and fast, which is a large part of their appeal to performance-focused teams and modern projects.
For detection, this compiler model is the crucial context: because Svelte compiles away, there is no Svelte runtime global to check the way you would for React (__REACT) or Vue. So you detect SvelteKit — the app framework — through its build-output paths, its link-preloading attributes, and its hydration bootstrap, rather than a library runtime. Its presence signals a team that deliberately chose Svelte's compile-time approach for speed and a clean developer experience, which usually indicates a modern, performance-conscious build.
How SvelteKit renders and hydrates
A SvelteKit site serves its build output from a /_app/ path, with hashed, cache-immutable assets under /_app/immutable/ (chunks, entry points and CSS). Server-rendered pages ship HTML plus an inline hydration bootstrap that references a window.__sveltekit_<hash> object and invokes SvelteKit's start function with the route data and node information needed to hydrate the page. So even though there is no Svelte runtime global, the __sveltekit_-prefixed object and the start-up script are present in server-rendered pages.
SvelteKit also adds data-sveltekit-* attributes to control its intelligent preloading: data-sveltekit-preload-data (fetch a route's data on hover/tap) and data-sveltekit-preload-code (fetch its code), often set on the <body> or on individual links. These attributes are distinctive and easy to spot in the DOM. Static (prerendered) SvelteKit pages still ship the /_app/ assets and the hydration bootstrap. Knowing this — the /_app/ (and /_app/immutable/) paths, the data-sveltekit-* attributes, and the __sveltekit_ global — makes detection reliable despite the absence of a runtime global.
How to tell if a website uses SvelteKit
Confirm at least two of the following.
1. Check asset paths. In the Network tab, look for assets served from /_app/ (especially /_app/immutable/). This path is characteristic of SvelteKit's build output.
2. Inspect link attributes. Look for data-sveltekit-preload-data and data-sveltekit-preload-code attributes on links or a wrapping element.
3. Use the console / source. Search the source for __sveltekit_ or _app/immutable, and check the console for a __sveltekit_<hash> global or the inline start-up script.
4. View the page source. The hydration bootstrap script that imports from /_app/immutable/ and starts the kit confirms SvelteKit.
5. Note the lightweight output. SvelteKit sites tend to ship little JavaScript (no framework runtime), consistent with Svelte's compile-time model — corroborating, though the /_app/ paths are decisive.
What the SvelteKit signals look like
<body data-sveltekit-preload-data="hover">
<link rel="modulepreload" href="/_app/immutable/entry/start.[hash].js">
<script type="module">
import { start } from "/_app/immutable/entry/start.[hash].js";
start({ … }, document.querySelector("#…"), [ … ]); // references __sveltekit_<hash>
</script>
The combination of /_app/ (and /_app/immutable/) asset paths, data-sveltekit-* attributes, and the __sveltekit_ hydration bootstrap is conclusive.
SvelteKit versus other frameworks — avoiding false positives
Match the asset path and attributes to keep frameworks distinct. SvelteKit uses /_app/ and data-sveltekit-*; Next.js uses /_next/ and __NEXT_DATA__; Nuxt uses /_nuxt/ and __NUXT__; Remix uses __remixContext. The /_app/immutable/ path and the data-sveltekit-preload-* attributes are unique to SvelteKit. The key conceptual difference is that there is no Svelte runtime global — so do not look for one; the framework signals are the identifier. A plain Svelte project bundled without SvelteKit (just the Svelte compiler with a custom setup) will lack the /_app/ paths and data-sveltekit-* attributes, so those are what specifically identify SvelteKit rather than Svelte alone.
How reliable is each SvelteKit signal?
The /_app/immutable/ asset path is definitive, as is the __sveltekit_ hydration bootstrap. The data-sveltekit-preload-* attributes are equally strong and characteristic. The lightweight JavaScript footprint is corroborating but not decisive alone. The weakest situation is a static SvelteKit export with minimal client JS, but even then the /_app/ assets and the hydration script are present. As a rule, the /_app/ paths plus the data-sveltekit-* attributes confirm SvelteKit immediately, and there is essentially no false-positive risk.
What a SvelteKit build reveals about a site
Finding SvelteKit signals a team that deliberately chose Svelte's compile-time model for a fast, lightweight application. That is a performance-conscious, somewhat early-adopter choice — Svelte and SvelteKit attract developers who value minimal JavaScript, clean syntax and speed. SvelteKit is common on performance-focused web apps, content sites, marketing sites and modern projects, often where load time and a small bundle matter. Its presence tells you the site is a real application built with care, by a team comfortable with a newer, leaner framework. If you sell developer tooling, edge hosting, or performance services, a SvelteKit site marks a technically discerning, performance-minded buyer. The lightweight output also tends to correlate with good Core Web Vitals, which is useful context.
What finding SvelteKit means for sales, agencies and competitive research
For sales and prospecting, SvelteKit marks a performance-focused, modern engineering team — a fit for developer tools, edge hosting, and performance or front-end services. Its early-adopter skew suggests a team open to newer tools.
For agencies and consultants, finding SvelteKit tells you the client runs a lean, compile-time framework, so engagements can focus on performance, SSR/SSG strategy, or feature work within SvelteKit. It signals a technically capable, performance-minded client.
For competitive and market research, SvelteKit adoption reveals a competitor's preference for a lightweight, fast framework. Spotting it suggests they prioritise performance and developer experience, useful when benchmarking page speed and engineering culture.
SvelteKit in the wider stack
SvelteKit sits at the centre of a Svelte application stack, built with Vite and deployed via an adapter to a target platform — static hosting for prerendered sites, or Node/edge runtimes (Vercel, Netlify, Cloudflare) for SSR. Because the output is lightweight, SvelteKit sites often pair with privacy-friendly analytics, a headless CMS for content sites, and modern hosting. For an auditor, the valuable details are whether the site is prerendered or SSR, the hosting/adapter target, the preload strategy (from the data-sveltekit-preload-* value), and any headless CMS or data backend; together these reveal a performance-focused team's architecture and how they balance static and dynamic rendering.
A quick SvelteKit confirmation walkthrough
Open the site with developer tools on the Network panel and look for assets loaded from /_app/ (especially /_app/immutable/) — characteristic of SvelteKit. Switch to the Elements panel and inspect the <body> and links for data-sveltekit-preload-data/data-sveltekit-preload-code attributes. View the source and search for __sveltekit_ or _app/immutable to find the hydration bootstrap script. Note the small JavaScript footprint consistent with Svelte's compile-time model. The /_app/ paths plus the data-sveltekit-* attributes are enough to confirm SvelteKit.
A quick SvelteKit detection checklist
- Check the Network tab for
/_app/and/_app/immutable/asset paths — characteristic. - Inspect links/body for
data-sveltekit-preload-data/-preload-codeattributes. - Search the source for
__sveltekit_and the hydration bootstrap script. - Remember Svelte compiles away — there is no runtime global to find.
- Note the lightweight JS footprint as corroboration.
- Distinguish SvelteKit (
/_app/,data-sveltekit-*) from Next.js (/_next/) and Nuxt (/_nuxt/).
Detecting SvelteKit at scale
Checking one site is quick, but mapping framework adoption across many domains — to find performance-focused, modern engineering teams — calls for automation. StackOptic detects SvelteKit and thousands of other technologies from a real browser, reading asset paths and DOM attributes so it catches a compile-time framework that leaves no runtime global. That last point matters: scanners that only look for framework runtime globals miss SvelteKit entirely, so a real-browser scan that inspects the rendered DOM is the only reliable way to map Svelte adoption across a market at scale. For related reading, see our guides to telling if a website is built with Svelte or SvelteKit and checking if a website uses React, Vue or Angular, and the full SvelteKit technology profile.
Frequently asked questions
What is the fastest way to tell if a site uses SvelteKit?
Open the Network tab and look for assets loaded from a /_app/ path (especially /_app/immutable/). That path is characteristic of SvelteKit's build output. You can also inspect links for data-sveltekit-preload-data attributes and check the console for a __sveltekit_<hash> global.
What are the data-sveltekit-* attributes?
SvelteKit adds attributes like data-sveltekit-preload-data and data-sveltekit-preload-code to links (or a wrapping element) to control its intelligent preloading of route data and code on hover or tap. Seeing these data-sveltekit-* attributes is a strong, characteristic SvelteKit signal.
Why can't I just look for a Svelte runtime global?
Svelte is a compiler: it turns components into efficient vanilla JavaScript at build time rather than shipping a framework runtime, so there is no Svelte global to check the way there is for React or Vue. Instead, detect SvelteKit (the app framework) via its /_app/ asset paths, data-sveltekit-* attributes and __sveltekit_ hydration global.
What is the __sveltekit_ global?
SvelteKit embeds a hydration bootstrap that references a window.__sveltekit_<hash> object and calls its kit start function with the route data. Finding a __sveltekit_-prefixed global or the inline start-up script is a definitive SvelteKit signal.
What does it mean if a site is built with SvelteKit?
SvelteKit is the official application framework for Svelte, offering routing, SSR/SSG and a fast, lightweight output thanks to Svelte's compile-time model. Finding it signals a team that prioritised performance and a modern developer experience, common in performance-focused apps, content sites and modern projects.
Analyse any website with StackOptic
Get the full technology stack, performance, security and SEO report in seconds — free.
Analyse a websiteRelated articles
How to Tell If a Website Uses Heap
Heap (Heap Analytics) autocaptures product events. Detect it via the cdn.heapanalytics.com script, the global heap object, heapanalytics.com beacons and _hp2 cookies.
How to Tell If a Website Uses Foundation
Foundation (by Zurb) is a responsive front-end framework. Detect it via its grid classes (row/columns, grid-x/cell), data-* component attributes and the foundation.css/js files.
How to Tell If a Website Uses Crisp
Crisp is a developer-friendly, affordable live-chat and messaging tool. Detect it via the client.crisp.chat/l.js script, the window.$crisp object and the CRISP_WEBSITE_ID value.