How to Tell if a Website Is Built with Svelte or SvelteKit

If you want to know whether a website is built with Svelte or SvelteKit, the fastest answer is to view the page source and look for CSS classes in the form svelte-<hash> — for example class="svelte-1a2b3c". Svelte's compiler adds those hashed suffixes to scope styles to a component, and they are close to definitive for Svelte. To confirm SvelteKit specifically — the application framework built on top of Svelte — look for data-sveltekit-* attributes in the HTML and JavaScript chunks loading from an /_app/ folder in the DevTools Network tab. This guide walks through every signal, explains the Svelte-versus-SvelteKit distinction, and shows how to read it all in under a minute.

It sits alongside the broader framework guide, how to check what JavaScript libraries a website uses, and the wider how to find out what technology a website uses.

What Svelte and SvelteKit are, briefly

Svelte is an open-source UI framework with an unusual approach: rather than shipping a large runtime to the browser to interpret a virtual DOM (as React does), Svelte is a compiler. It turns your components into small, mostly vanilla-JavaScript bundles at build time, so the browser runs lean, purpose-built code with minimal framework overhead. The practical effect is small bundles and fast pages.

SvelteKit is the application framework built on top of Svelte — the equivalent of what Next.js is to React. It adds the things plain Svelte leaves to you: file-based routing, server-side rendering and static generation, data loading, and an optimised build pipeline (powered by Vite). For detection, the distinction matters: Svelte is the component layer with its scoped-class fingerprint, while SvelteKit adds its own application-level markers on top. A site can use Svelte components without the full framework, but a great many modern Svelte sites are SvelteKit, and the SvelteKit markers are usually present.

Signal 1: svelte-<hash> scoped CSS classes

The single most reliable Svelte fingerprint is its scoped styling. To stop a component's CSS leaking to the rest of the page, Svelte appends a unique hashed class to every element styled within that component — and to the matching CSS rule. So in the HTML you will see classes like:

<div class="card svelte-1a2b3c">...</div>

and in the stylesheet a rule like .card.svelte-1a2b3c { ... }. Open View Source (Ctrl/Cmd + U) and search the page for svelte-; if you find these hashed svelte-<hash> classes on elements and styles, you are almost certainly looking at a Svelte-built site. The pattern is specific to Svelte's compiler — no other common framework produces exactly this scoped-class format — which makes it a clean, strong signal that is present in the server-rendered HTML before any JavaScript runs.

Signal 2: data-sveltekit-* attributes

SvelteKit announces itself with its own HTML attributes. The most common is data-sveltekit-preload-data, which SvelteKit adds to enable its link-preloading behaviour, but you may also see data-sveltekit-preload-code, data-sveltekit-reload and similar. Searching the source for data-sveltekit is a direct test for the framework: these attributes are SvelteKit-specific and are written into the markup. Finding them tells you the site is not merely using Svelte components but is built with the full SvelteKit application framework, with its routing and navigation features in play.

Signal 3: the /_app/ asset folder and hydration payload

SvelteKit serves its build artefacts from an /_app/ folder. When you load a SvelteKit site and watch the Network tab, you will see requests to URLs like /_app/immutable/chunks/<hash>.js and /_app/immutable/entry/start.<hash>.js — the immutable segment reflects the framework's content-hashed, long-cacheable assets. The /_app/ prefix is specific to SvelteKit's output and is a strong corroborating signal.

Alongside the chunks, SvelteKit injects a hydration payload to bring the server-rendered page to life on the client. In the source you will typically find an inline script that kicks off the app — a kit.start(...) call, or data assigned to a __sveltekit_<hash> global — referencing the /_app/ build and the route's data. This is how SvelteKit hydrates the page with what the server already computed, and its presence confirms client-side hydration of a server-rendered SvelteKit app. (Newer versions vary the exact shape of this payload, so treat its presence as a positive and its precise form as version-dependent.)

Signal 4: small bundles and a Vite build

The fourth signal is a characteristic rather than a string. Because Svelte compiles components instead of shipping a big runtime, Svelte and SvelteKit pages tend to be lightweight and fast, with comparatively little framework JavaScript relative to the interactivity on offer. SvelteKit also builds with Vite, so you may spot Vite-style hashed module filenames and, in development builds, Vite's client. This lean profile — small JS, fast hydration — combined with the markers above, fits the Svelte fingerprint and is part of why teams choose it.

The signal table

Signal	Where to find it	What it means
class="... svelte-<hash>"	View Source / Elements	Svelte scoped styling — strongest Svelte signal
.foo.svelte-<hash> CSS rule	Stylesheet / View Source	Matching scoped style — confirms Svelte
data-sveltekit-preload-data etc.	View Source	SvelteKit application framework — strong
/_app/immutable/... asset URLs	Network tab, View Source	Standard SvelteKit build output — strong
__sveltekit_<hash> / kit.start(	View Source	SvelteKit hydration payload
Small bundles, fast hydration	Network tab	Svelte's compiled, lean profile

Method 1: View Source

The quickest single check is View Source. Open the page, press Ctrl/Cmd + U, and use the in-page find to search for svelte-, data-sveltekit and _app/. If you find svelte-<hash> classes, that is Svelte; if you also find data-sveltekit-* attributes and references to /_app/, that is SvelteKit specifically. Scanning the source also lets you spot the hydration script. This works because Svelte's scoped classes and SvelteKit's attributes are baked into the server-rendered HTML, so they are present before any JavaScript runs — which is exactly why a static source view catches them.

Method 2: the DevTools Network tab

For a live view, open DevTools (F12), go to the Network tab and reload. Filter to JS and look for the parade of /_app/immutable/chunks/*.js files and the start.<hash>.js entry — these are unmistakably SvelteKit. The Network tab is valuable because it shows what the browser actually fetches and confirms the framework is genuinely powering the page. The volume of JavaScript is informative too: a SvelteKit page typically pulls relatively little framework code, in keeping with Svelte's compiled approach. To identify any other libraries loading alongside it, the same view feeds into how to check what JavaScript libraries a website uses.

Method 3: Wappalyzer and BuiltWith

For a one-click read, the Wappalyzer browser extension and BuiltWith both recognise Svelte and SvelteKit and list them in their framework section, often alongside Vite and the hosting. They are convenient for a quick confirmation and for capturing the whole stack at once. As always, treat their output as a strong starting point and verify the important calls against the raw signals — the svelte-<hash> classes, data-sveltekit-* attributes and /_app/ paths are the ground truth, and a quick View Source confirms what an extension reports.

A worked example

Say you are sizing up a startup's marketing site. You open View Source and search for svelte- — and there they are: class="hero svelte-1x9k2p" on several elements, with matching .hero.svelte-1x9k2p rules in the inline styles. That points to Svelte. You keep going: the <body> carries a data-sveltekit-preload-data="hover" attribute, and near the bottom of the source an inline script calls into a kit.start(...) referencing /_app/. The Network tab confirms it — a handful of /_app/immutable/chunks/*.js files and a start.<hash>.js entry, and not much other JavaScript. Every signal lines up: this is a SvelteKit application with server-side rendering and client hydration, built lean. In about a minute you have the framework, that it is the full SvelteKit (not just Svelte components), and a read on its performance approach.

Distinguishing Svelte/SvelteKit from other frameworks

It is worth knowing how Svelte differs from its peers so you do not misattribute. Next.js (React) exposes /_next/static/ and a __NEXT_DATA__ script — not svelte- classes or /_app/. Nuxt (Vue) exposes /_nuxt/ and a __NUXT__ payload. Astro writes a generator meta tag reading Astro and wraps interactive parts in <astro-island> elements. A plain client-side React or Vue app mounts into a root element with no scoped svelte- classes. So the svelte-<hash> scoped class is the thing that specifically points to Svelte, and the data-sveltekit-* plus /_app/ markers are what name SvelteKit on top of it.

The Svelte-versus-SvelteKit call itself follows a simple rule. svelte-<hash> classes but no SvelteKit markers suggests Svelte components used without the full framework (or a different Svelte-based setup). svelte-<hash> classes plus data-sveltekit-* plus /_app/ means SvelteKit, with high confidence. Reading the component-level signal and the application-level signal separately keeps the attribution precise.

It also helps to recognise SvelteKit's rendering modes. With server-side rendering or prerendering, the meaningful HTML is present in View Source and the hydration payload is populated, so detection is easy and the content is crawlable. With heavier client-side rendering, the initial HTML may be thinner — but the /_app/ asset requests still fire, so the path signal carries the detection. Recognising which mode a site uses is a bonus insight into how the team has balanced performance, SEO and interactivity.

Why the framework matters

Knowing a site runs SvelteKit tells you more than a label. It implies a rendering model (server-side rendering or static generation with client hydration), which has performance and SEO consequences. It signals a modern, performance-focused stack — Svelte's compiled approach and small bundles are chosen by teams that value speed and developer experience. And it points to a current build pipeline (Vite) and a team comfortable with the leading edge of the framework world. For competitive research, sales qualification, hiring or partnership scoping, the framework is one of the most informative single facts about a site, and SvelteKit in particular flags a lean, well-engineered front end.

How reliable is Svelte/SvelteKit detection?

Very reliable. The svelte-<hash> scoped classes are intrinsic to how Svelte compiles styles, and SvelteKit's data-sveltekit-* attributes and /_app/ asset folder are intrinsic to how the framework ships pages — so these markers are present on the large majority of Svelte and SvelteKit sites and are not used by unrelated tools. The main nuances are version-dependent details (the exact shape of the hydration payload changes between releases) and the Svelte-versus-SvelteKit distinction (lean on the data-sveltekit-* and /_app/ markers to confirm the full framework). Combine the scoped classes, the attributes and the asset paths, and you can state "this is Svelte/SvelteKit" with genuine confidence.

The workflow

1. View Source and search for svelte-, data-sveltekit and _app/.
2. Open the Network tab and watch for /_app/immutable/chunks/*.js and the start.<hash>.js entry.
3. Confirm the scoped classes (svelte-<hash>) as the Svelte foundation.
4. Check for SvelteKit markers (data-sveltekit-*, the hydration payload) to name the full framework.
5. Combine the signals — svelte- plus /_app/ plus data-sveltekit-* means SvelteKit.

Go deeper

• A close cousin to detect: how to tell if a website is built with Astro.
• The libraries alongside it: how to check what JavaScript libraries a website uses.
• The whole stack: how to find out what technology a website uses.
• The styling layer: how to find what fonts and colours a website uses.

Want the framework, hosting and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.