Global Styles | Svelte 5 Reference

When You Need to Cross the Boundary

Scoping is Svelte’s default, and it’s the right default. Components that contain their own styles are predictable, portable, and easy to reason about. But there are genuine situations where you need CSS to reach beyond a component’s boundary:

Application-wide base styles — a CSS reset, typography defaults, or box-sizing: border-box applied to every element in the document need to apply everywhere, not just inside one component. Third-party library DOM — a date picker, rich text editor, or charting library injects its own HTML with its own class names, and none of those elements have Svelte’s scoping hash. Content injected at runtime via {@html} never passes through the Svelte compiler, so it receives no scoping hashes. Global keyframe animations — an animation that multiple components or external libraries need to reference by name must exist in the global CSS namespace.

Svelte gives you two distinct approaches for all of these situations: inline escape hatches using the :global modifier and block syntax within component style blocks, and external CSS file imports. Understanding both — and knowing when to choose which — is what this article covers.

Approach 1: The `:global()` Modifier

The :global() modifier wraps any part of a CSS selector to remove scoping from that part. The selector still lives inside the component’s style block, but the wrapped portion compiles to a plain CSS selector with no hash attached.

Full Global Reach

At its simplest, wrapping an entire selector in :global() makes it apply to every matching element in the document:

/* Component.svelte <style> block */

/* Scoped: only <p> elements in THIS component */
p {
	color: blue;
}

/* Global: applies to <body> everywhere in the application */
:global(body) {
	margin: 0;
	font-family: system-ui, sans-serif;
}

When you write :global(body), Svelte outputs body with no hash — an ordinary CSS selector that participates in the global cascade like any stylesheet rule.

Scoped Anchor + Global Descendant

The most useful pattern combines a scoped selector with a global descendant. The scoped part anchors the rule to a specific region of the page, while :global() allows the descendants to match without needing a hash:

/* Component.svelte <style> block */
/* .prose is scoped to this component */
/* The descendants match anything inside .prose, regardless of which component generated it */
.prose :global(h1) {
	font-size: 2rem;
	margin-bottom: 1rem;
}
.prose :global(h2) {
	font-size: 1.5rem;
	margin-bottom: 0.75rem;
}
.prose :global(p) {
	line-height: 1.7;
	margin-bottom: 1rem;
}
.prose :global(code) {
	background: #f4f4f5;
	padding: 0.125rem 0.375rem;
	border-radius: 0.25rem;
	font-size: 0.875em;
}
.prose :global(blockquote) {
	border-left: 3px solid #e5e7eb;
	padding-left: 1rem;
	color: #6b7280;
	font-style: italic;
}

This pattern is essential for {@html} content. HTML injected at runtime never passes through Svelte’s compiler, so the injected elements carry no scoping hash. A plain scoped p { ... } rule won’t match them. By anchoring to .prose (which is scoped to your component) and using :global() for descendants, you get styles that only activate inside your component’s container — targeted global reach rather than document-wide reach.

The compiled output makes this concrete:

/* .prose gets the hash; descendants don't */
.prose.svelte-abc123 h1  { ... }
.prose.svelte-abc123 h2  { ... }
.prose.svelte-abc123 p   { ... }

Matching Externally Added Classes

A third form lets you target an element that is scoped to your component but whose class is added by an external source — a library, an animation system, or JavaScript directly:

/*
 * Matches <p> elements in THIS component that also have .big and .red,
 * regardless of whether those classes were set by Svelte, a library, or JS.
 */
p:global(.big.red) {
	font-size: 2rem;
	color: crimson;
}

This compiles to p.svelte-abc123.big.red. The p is scoped (carries the hash), but .big and .red are global — they will match whether those classes came from Svelte, from element.classList.add(), or from a third-party library.

Approach 2: The `:global {}` Block

When you need to make several rules global at once, writing :global() around every individual selector gets repetitive. The :global {} block is the ergonomic alternative — every selector written inside the block is treated as global, including deeply nested ones.

These two style declarations produce identical compiled CSS:

/* Approach A: one :global() wrapper per rule */
.editor :global(.toolbar) {
	display: flex;
}
.editor :global(.toolbar button) {
	cursor: pointer;
}
.editor :global(.content) {
	padding: 1rem;
}
.editor :global(.content:focus) {
	outline: none;
}

/* Approach B: one :global block covers all of them */
.editor :global {
	.toolbar {
		display: flex;
	}
	.toolbar button {
		cursor: pointer;
	}
	.content {
		padding: 1rem;
	}
	.content:focus {
		outline: none;
	}
}

The block form is preferred when you have a suite of rules for a container whose internals you do not control. The scoped anchor (.editor) appears once at the top and everything inside reads as a clean list of global descendants without the repetition.

Without a scoped anchor, the block makes all its selectors completely document-wide — useful for application-level resets and base styles in the root layout:

/* +layout.svelte <style> block */
:global {
	*,
	*::before,
	*::after {
		box-sizing: border-box;
		margin: 0;
		padding: 0;
	}
	html {
		font-family: system-ui, sans-serif;
		line-height: 1.6;
	}
	body {
		min-height: 100dvh;
		color: #1a1a1a;
	}
	img,
	picture,
	video,
	canvas,
	svg {
		display: block;
		max-width: 100%;
	}
	input,
	button,
	textarea,
	select {
		font: inherit;
	}
}

The nested block form is preferred, but you can also write it as a flat selector where everything after the :global keyword is unscoped: .editor :global .toolbar { ... }. This is valid but less readable for multiple rules since the global scope is implicit rather than visually bounded.

Global Keyframe Animations

Svelte scopes @keyframes using the same hash mechanism as selectors. Two components can both define @keyframes spin without clashing — each compiles to a unique internal name. When you need a keyframe to be globally referenceable — because a third-party library references it by name, or because you want to share it across components — prefix the name with -global-:

/*
 * The -global- prefix is stripped at compile time.
 * The keyframe is emitted as "fadeIn" with no hash,
 * accessible to any element in the application.
 */
@keyframes -global-fadeIn {
	from {
		opacity: 0;
		transform: translateY(4px);
	}
	to {
		opacity: 1;
		transform: translateY(0);
	}
}

Any component can then reference animation: fadeIn 0.2s ease and reach this keyframe, just as it would reference a keyframe in an external stylesheet.

CSS Nesting with `:global()`

Modern CSS nesting and Svelte’s :global() compose cleanly. This is particularly powerful when styling a third-party component whose internal elements you want to target from a neatly organized style block:

/* Editor.svelte <style> block */
.editor {
	/* The .editor class is scoped to this component */
	border: 1px solid #e5e7eb;
	border-radius: 8px;
	overflow: hidden;

	/* :global() inside a nested rule reaches the library's internal DOM */
	:global(.ProseMirror) {
		padding: 1rem;
		outline: none;
		min-height: 200px;

		/* Nesting :global() inside another :global() continues the chain */
		:global(p) {
			margin-bottom: 0.75rem;
			line-height: 1.7;
		}
		:global(h1) {
			font-size: 1.75rem;
			font-weight: 700;
		}
		:global(blockquote) {
			border-left: 3px solid #e5e7eb;
			padding-left: 1rem;
			color: #6b7280;
		}
	}
}

Approach 3: External CSS File Imports

The :global mechanisms work inline — the global CSS lives inside a component’s style block. But sometimes you want global styles in their own external file: a shared reset, a third-party library’s stylesheet, a design token sheet. Svelte and SvelteKit support three distinct ways to bring those files in.

Method 1: ES Module Import in `<script>`

<!-- +layout.svelte -->
<script>
	import '$lib/styles/global.css'

	let { children } = $props()
</script>

{@render children()}

When the component mounts, the imported CSS is injected into <head>. It stays there even after the component unmounts — which is exactly the behaviour you want for application-wide base styles. Vite hashes the filename in production (global-a3f2b1.css) for cache busting, and tracks the import for HMR so the browser updates instantly when you edit the file.

Warning

Do not import global CSS in app.html as a <link> tag. Vite does not track those files for HMR — changes to the CSS require a full dev server restart to appear in the browser.

Method 2: `@import` Inside the Style Block

Vite also supports CSS @import within component style blocks. The external file’s contents are folded into the component’s compiled stylesheet at build time:

/* This goes inside a component's <style> block */
/* Use a relative path or the $lib alias */

/* Example: sharing base form styles across a family of input components */
/* @import '$lib/styles/form-base.css'; */

.text-input {
	/* Component-specific overrides on top of the shared base */
	font-family: var(--font-mono);
}

The behaviour is the same as Method 1 — the styles persist after the component unmounts — but this form keeps the import visible inside the style block, which is the natural place a reader expects to find styling decisions. Vite deduplicates the output in production, so the file is not emitted twice even when multiple components import it.

Method 3: `?url` Import for Reactive Stylesheets

The ?url import gives you the resolved URL of a CSS file as a string, rather than injecting it immediately. You then render a <link> element yourself via <svelte:head>:

<!-- AdminLayout.svelte -->
<script>
	import adminStylesUrl from '$lib/styles/admin.css?url'

	let { children } = $props()
</script>

<svelte:head>
	<link rel="stylesheet" href={adminStylesUrl} />
</svelte:head>

{@render children()}

This is the only import method where the stylesheet is removed from <head> when the component unmounts. The <link> element is part of Svelte’s reactive rendering output — when the AdminLayout component is destroyed on navigation away, Svelte removes the <link> entirely. This makes it the right choice for route-scoped stylesheets that should only be present while a specific part of the application is active.

Info

For light/dark mode switching across the whole application, CSS custom properties are a better fit than swapping stylesheet links. Toggling a class on <html> that changes which variable values are active is instant and causes no flash. Swapping a <link> causes the browser to fetch and parse a new stylesheet, which produces a brief unstyled state.

The Cascade Flows In

There is an important asymmetry in how Svelte’s scoping works that catches developers by surprise: scoping prevents styles from leaking out of a component, but it does not prevent the CSS cascade from flowing in.

When you import a global stylesheet that defines a { color: #3b82f6; text-decoration: underline; }, those rules apply to <a> elements inside every scoped component in your application — including ones with their own scoped a rules. A scoped component’s a.svelte-abc123 { font-weight: 600 } adds its own styling on top; it doesn’t block the global rule from applying.

Specificity determines the winner for any individual property. The scoped rule’s compiled form a.svelte-abc123 has specificity 0,1,1 (one class and one element), which is higher than the global a rule’s 0,0,1 (one element alone). So the scoped font-weight: 600 wins over a global a { font-weight: 400 }. But inherited properties and properties the scoped rule does not touch still flow in from the global stylesheet normally.

This is intentional — your global stylesheet can set sensible defaults for links, headings, and paragraphs that serve as baselines everywhere, and individual scoped components layer their own rules on top. The isolation is one-directional by design.

Practical Patterns

Pattern 1: Styling a Third-Party Library

Libraries like date pickers, rich text editors, and carousels inject their own DOM with their own class names. Use a scoped anchor with :global() descendants to style them without touching anything outside your component:

<!-- PickerWrapper.svelte -->
<script>
	import DatePicker from 'some-date-library'
	let selectedDate = $state(null)
</script>

<div class="picker-wrapper">
	<DatePicker bind:value={selectedDate} />
</div>

/* In the <style> block */
.picker-wrapper {
	margin-bottom: 1rem;
}

/* Library's classes, scoped to our wrapper — don't affect other instances */
.picker-wrapper :global(.dp-calendar) {
	border: 1px solid #e5e7eb;
	border-radius: 8px;
	box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
}
.picker-wrapper :global(.dp-day) {
	width: 2.5rem;
	height: 2.5rem;
	border-radius: 50%;
}
.picker-wrapper :global(.dp-day:hover) {
	background: #dbeafe;
}
.picker-wrapper :global(.dp-day.selected) {
	background: #3b82f6;
	color: white;
}

The .picker-wrapper anchor means these rules only activate inside your component’s container. If the same library is used elsewhere on the page, your overrides do not affect it.

Pattern 2: Application-Wide Base Styles in the Root Layout

The root +layout.svelte is the right home for application-wide CSS. You can write it inline with :global {} or import an external file — both are valid, and the choice is mainly organisational:

<!-- +layout.svelte — inline approach -->
<script>
	let { children } = $props()
</script>

{@render children()}

/* In the <style> block of +layout.svelte */
:global {
	*,
	*::before,
	*::after {
		box-sizing: border-box;
		margin: 0;
		padding: 0;
	}
	html {
		font-family: system-ui, sans-serif;
		line-height: 1.6;
	}
	body {
		min-height: 100dvh;
		color: #1a1a1a;
	}
	img,
	picture,
	video,
	canvas,
	svg {
		display: block;
		max-width: 100%;
	}
	input,
	button,
	textarea,
	select {
		font: inherit;
	}
}

Or equivalently using file imports:

<!-- +layout.svelte — file import approach -->
<script>
	import '$lib/styles/reset.css'
	import '$lib/styles/base.css'

	let { children } = $props()
</script>

{@render children()}

Info

Keep global styles centralized — either inline in the root layout or in one or two dedicated files imported there. Scattering :global rules across many components makes your stylesheet nearly impossible to audit or debug.

Pattern 3: Styling `{@html}` Content

HTML injected via {@html} never passes through the Svelte compiler, so it has no scoping hashes. A scoped p { ... } rule will not match those paragraphs. Use the scoped-anchor + :global() pattern:

<!-- Prose.svelte -->
<script>
	let { content } = $props()
</script>

<div class="prose">
	{@html content}
</div>

/* In the <style> block */
.prose :global(h1) {
	font-size: 2rem;
	margin-bottom: 1rem;
}
.prose :global(h2) {
	font-size: 1.5rem;
	margin-bottom: 0.75rem;
}
.prose :global(p) {
	line-height: 1.7;
	margin-bottom: 1rem;
}
.prose :global(a) {
	color: #3b82f6;
	text-decoration: underline;
}
.prose :global(code) {
	background: #f4f4f5;
	padding: 0.125rem 0.375rem;
	border-radius: 4px;
	font-size: 0.875em;
}
.prose :global(blockquote) {
	border-left: 3px solid #e5e7eb;
	padding-left: 1rem;
	color: #6b7280;
	font-style: italic;
}

Pattern 4: Styling Snippet Content from a Parent

When you render a snippet with {@render children()}, the snippet’s markup was authored in the parent component. Svelte scopes it to the parent, not to the child that renders it. If the child needs to apply styles to that content, it needs :global():

<!-- Accordion.svelte -->
<script>
	let { title, children } = $props()
	let isOpen = $state(false)
</script>

<div class="accordion">
	<button class="accordion-header" onclick={() => (isOpen = !isOpen)}>
		{title}
		<span class="chevron" class:rotated={isOpen}>▶</span>
	</button>
	{#if isOpen}
		<div class="accordion-body">
			{@render children()}
		</div>
	{/if}
</div>

/* In the <style> block */
.accordion {
	border: 1px solid #e5e7eb;
	border-radius: 8px;
	overflow: hidden;
}

.accordion-header {
	width: 100%;
	padding: 1rem;
	display: flex;
	justify-content: space-between;
	align-items: center;
	background: #f9fafb;
	border: none;
	cursor: pointer;
	font-size: 1rem;
	font-weight: 500;
}
.accordion-header:hover {
	background: #f3f4f6;
}

.chevron {
	transition: transform 0.2s ease;
	font-size: 0.75rem;
}
.chevron.rotated {
	transform: rotate(90deg);
}

.accordion-body {
	padding: 1rem;
	border-top: 1px solid #e5e7eb;
}

/*
 * The snippet was authored in the parent, so its elements carry
 * the parent's scoping hash. :global() lets us reach into it.
 */
.accordion-body :global(> *:not(:last-child)) {
	margin-bottom: 0.75rem;
}
.accordion-body :global(> p) {
	line-height: 1.7;
	color: #4b5563;
}

Choosing Between `:global` and File Imports

Both approaches let you write CSS that applies beyond a single component. The decision comes down to where the styles live and whether they need to be removed on component unmount.

Use inline :global when the CSS is tightly coupled to a specific component — styling a third-party library you wrap, applying reset rules that you think of as belonging to the layout, or styling {@html} content that arrives through a particular component. The styles and the component that needs them stay together in one file.

Use file imports when the CSS is large enough to warrant its own file or is genuinely reusable across multiple projects. A design token sheet, a third-party library’s base CSS, a company-wide typography stylesheet — these are not owned by any particular component and are better managed as standalone files imported once at the root layout.

Use ?url imports specifically when you need the stylesheet removed when the component unmounts — route-scoped presentations, print previews, or any stylesheet that should not bleed into sibling routes.

When a parent needs to adjust a child component’s visual appearance without breaking encapsulation, CSS custom properties (covered in the CSS Custom Properties article) are the cleaner alternative to any of the above. CSS variables cross component boundaries by design and do not require :global at all.

Common Mistakes

Overusing :global() for your own elements. If the elements are in your template, use scoped styles — they are more specific, isolated, and the compiler will warn you if a selector goes unused. :global() is an escape hatch for elements you do not control.

Scattering :global rules across components. If two components both write :global(body) rules, the one that loads last wins — and load order can change depending on routing and bundling. Keep all document-level globals in one place: the root layout.

Forgetting that {@html} content is not scoped. A scoped p { color: blue } will not match paragraphs injected by {@html}. Use .container :global(p) { color: blue } where .container is the scoped wrapper element.

Importing global CSS in app.html. Vite does not track <link> tags in app.html for HMR — changes to the CSS file require a full dev server restart. Import from +layout.svelte instead.

Quick Reference

Full global — matches everywhere in the application:

:global(body) {
	margin: 0;
}

Controlled global — scoped anchor with global descendants:

.wrapper :global(h1) {
	color: red;
}

Matching an externally added class on a scoped element:

p:global(.highlight) {
	background: yellow;
}

Block form — multiple rules without repeating the wrapper:

:global {
	html {
		font-size: 16px;
	}
	body {
		margin: 0;
	}
}

.editor :global {
	.toolbar {
		display: flex;
	}
	.content {
		padding: 1rem;
	}
}

Global keyframe — referenceable by any element or library:

@keyframes -global-fadeIn {
	from {
		opacity: 0;
	}
	to {
		opacity: 1;
	}
}

ES module import — persists after component unmounts, tracked by Vite HMR:

import '$lib/styles/global.css'

?url import — reactive <link>, removed when component unmounts:

<script>
	import adminStylesUrl from '$lib/styles/admin.css?url'
</script>

<svelte:head>
	<link rel="stylesheet" href={adminStylesUrl} />
</svelte:head>

What’s Next?

With scoping and global styles covered, you have the full picture of how Svelte’s CSS boundaries work. The remaining articles cover how to make styling reactive and how to build component APIs around it:

Dynamic Class Binding — Toggling classes reactively based on component state
Dynamic Inline Styles — Setting CSS property values that depend on runtime data
CSS Custom Properties — The cleanest mechanism for parent-controlled component theming

When You Need to Cross the Boundary

Approach 1: The :global() Modifier

Full Global Reach

Scoped Anchor + Global Descendant

Matching Externally Added Classes

Approach 2: The :global {} Block

Global Keyframe Animations

CSS Nesting with :global()

Approach 3: External CSS File Imports

Method 1: ES Module Import in <script>

Method 2: @import Inside the Style Block

Method 3: ?url Import for Reactive Stylesheets

The Cascade Flows In

Practical Patterns

Pattern 1: Styling a Third-Party Library

Pattern 2: Application-Wide Base Styles in the Root Layout

Pattern 3: Styling {@html} Content

Pattern 4: Styling Snippet Content from a Parent

Choosing Between :global and File Imports

Common Mistakes

Quick Reference

What’s Next?

Approach 1: The `:global()` Modifier

Approach 2: The `:global {}` Block

CSS Nesting with `:global()`

Method 1: ES Module Import in `<script>`

Method 2: `@import` Inside the Style Block

Method 3: `?url` Import for Reactive Stylesheets

Pattern 3: Styling `{@html}` Content

Choosing Between `:global` and File Imports