HTML rendering with {@html} in Svelte - Deep Dive

Overview - HTML rendering with {@html}

What is it?

In Svelte, {@html} is a special syntax that lets you insert raw HTML code directly into your component's output. Instead of showing the HTML tags as text, it renders them as actual HTML elements on the page. This is useful when you have HTML content stored as a string and want it to appear as formatted content in your app.

Why it matters

Without {@html}, any HTML code inside a string would just show up as plain text, not as formatted content. This means you couldn't easily display dynamic HTML content from sources like user input, APIs, or rich text editors. {@html} solves this by injecting HTML so your app looks and behaves as expected.

Where it fits

Before learning {@html}, you should understand basic Svelte components, how to bind variables, and how Svelte handles text interpolation. After mastering {@html}, you can explore advanced content rendering, sanitizing HTML for security, and dynamic component creation.

Mental Model

Core Idea

The {@html} tag tells Svelte to treat a string as real HTML code and render it inside the component instead of plain text.

Think of it like...

Imagine you have a letter written on a piece of paper. Normally, you just read the words as text. Using {@html} is like unfolding a pop-up card inside the letter that shows a 3D shape instead of flat words.

Component Output Flow:

[Variable with HTML string] ---> {@html} directive ---> [Browser renders actual HTML elements]

Without {@html}:
[Variable with HTML string] ---> {variable} interpolation ---> [Browser shows raw HTML tags as text]

Build-Up - 6 Steps

1

Foundation

Basic text interpolation in Svelte

Concept: How Svelte normally inserts text variables into HTML.

In Svelte, you can show a variable's value inside your HTML using curly braces like {variable}. For example, if variable = 'Hello', writing

{variable}

will display the text 'Hello' literally, including the tags.

Result

The browser shows the HTML tags as plain text, not formatted content.

Understanding that Svelte escapes HTML by default helps you see why raw HTML strings don't render as elements.

2

Foundation

Why raw HTML strings don't render

Concept: Browsers treat inserted strings as text unless told otherwise.

When you insert a string with HTML tags into a webpage, the browser shows it as text to prevent security risks like code injection. This is why

{variable}

shows tags instead of formatting.

Result

HTML tags inside strings appear as text, preserving safety.

Knowing this default behavior explains why a special method is needed to render HTML from strings.

3

Intermediate

Using {@html} to render HTML strings

🤔Before reading on: Do you think {@html} escapes HTML tags or renders them as elements? Commit to your answer.

Concept: The {@html} directive tells Svelte to insert the string as real HTML, not escaped text.

By writing {@html variable}, Svelte inserts the string's content directly into the DOM. For example, if variable = 'Hello', then

{@html variable}

renders Hello in bold.

Result

The browser shows formatted HTML elements, not raw tags.

Understanding {@html} lets you display dynamic HTML content safely and effectively.

4

Intermediate

Security risks with {@html} usage

🤔Before reading on: Is it safe to use {@html} with any user input? Commit to your answer.

Concept: Injecting raw HTML can open security holes if the content is not sanitized.

If you use {@html} with untrusted content, malicious scripts can run in your app (XSS attacks). Always sanitize or trust the source before rendering HTML this way.

Result

Unsafe use can lead to security vulnerabilities.

Knowing the risks helps you avoid common security mistakes in real apps.

5

Advanced

Dynamic HTML rendering with reactive variables

🤔Before reading on: Will updating a variable used in {@html} automatically update the rendered HTML? Commit to your answer.

Concept: Svelte re-renders {@html} content reactively when the variable changes.

If you change the variable bound to {@html}, Svelte updates the DOM to reflect the new HTML. For example, changing variable from 'Hello' to 'Hi' updates the displayed content accordingly.

Result

Rendered HTML updates automatically with variable changes.

Understanding reactivity with {@html} enables dynamic content updates without manual DOM manipulation.

6

Expert

Internal handling and performance considerations

🤔Before reading on: Does Svelte parse and sanitize {@html} content internally? Commit to your answer.

Concept: Svelte inserts {@html} content as raw DOM nodes without parsing or sanitizing it internally.

When you use {@html}, Svelte directly sets the innerHTML of the element. It does not check or clean the HTML string. This means performance depends on browser DOM operations, and security depends on developer caution.

Result

Raw HTML is inserted quickly but requires external safety measures.

Knowing Svelte's minimal processing clarifies why developers must handle sanitization and performance optimization themselves.

Under the Hood

Svelte compiles {@html} into code that sets the innerHTML property of a DOM element with the provided string. This bypasses normal text escaping and inserts the HTML directly into the page's DOM tree. The browser then parses this string as HTML, creating elements and nodes accordingly. Svelte does not modify or sanitize the string; it trusts the developer to provide safe content.

Why designed this way?

This design keeps Svelte lightweight and fast by avoiding costly HTML parsing or sanitization during compilation. It gives developers full control over what HTML is inserted, allowing flexibility for trusted content or integration with sanitization libraries. Alternatives like automatic sanitization would add complexity and reduce performance.

Svelte Component
  │
  ├─ Variable with HTML string
  │
  ├─ {@html} directive compiles to innerHTML assignment
  │
  └─ Browser sets element.innerHTML = string
       │
       └─ Browser parses string into DOM nodes
            │
            └─ Rendered HTML elements appear on page

Myth Busters - 4 Common Misconceptions

Quick: Does {@html} automatically sanitize HTML to prevent XSS? Commit yes or no.

Common Belief: Many think {@html} cleans or sanitizes HTML content automatically.

Reality: Svelte does NOT sanitize {@html} content; it inserts raw HTML as-is.

Why it matters: Assuming automatic sanitization leads to security vulnerabilities if untrusted content is rendered.

Quick: Will using {@html} with static strings cause performance issues? Commit yes or no.

Common Belief: Some believe {@html} always slows down rendering significantly.

Reality: Using {@html} with static or small HTML strings has minimal performance impact; issues arise only with large or frequently changing content.

Why it matters: Misunderstanding performance can prevent developers from using {@html} where it is appropriate and efficient.

Quick: Does updating a variable used in {@html} require manual DOM updates? Commit yes or no.

Common Belief: Some think {@html} content is static and won't update automatically.

Reality: Svelte re-renders {@html} content reactively when the bound variable changes.

Why it matters: Knowing this prevents unnecessary manual DOM manipulation and simplifies dynamic content handling.

Quick: Can {@html} be used to insert scripts safely? Commit yes or no.

Common Belief: Some believe {@html} can safely insert and run JavaScript code.

Reality: While {@html} can insert