What if you could turn plain text with HTML tags into real, styled content instantly?
Why HTML rendering with {@html} in Svelte? - Purpose & Use Cases
Imagine you want to show some HTML content that comes as a string from a server, like a blog post or user comment with formatting.
You try to display it by just putting the string inside your page, but it shows as plain text with all the tags visible.
Manually inserting HTML strings as text means the browser won't render the tags as real HTML.
You'd have to write complex code to parse and insert elements, which is slow, error-prone, and unsafe.
Svelte's {@html} tag lets you insert raw HTML strings directly into your component's output.
This means the HTML inside the string renders properly as real elements, saving you from manual parsing and making your app dynamic and flexible.
let content = '<p><strong>Hello</strong> world!</p>'
<p>{content}</p>let content = '<p><strong>Hello</strong> world!</p>'
{@html content}You can safely and easily render dynamic HTML content from strings, making your app more interactive and rich.
Displaying user-generated blog posts or comments that include formatting like bold, italics, or links without losing the HTML structure.
Manual HTML strings show as plain text, not formatted.
{@html} renders raw HTML strings as real elements.
This makes dynamic content display simple and clean.
Practice
{@html} tag do in a Svelte component?Solution
Step 1: Understand {@html} purpose
The {@html} tag tells Svelte to treat the string as HTML, not plain text.Step 2: Compare with normal rendering
Normally, Svelte escapes HTML tags to show them as text, but {@html} renders them as real HTML.Final Answer:
It renders a string as actual HTML inside the component. -> Option BQuick Check:
{@html} = renders HTML [OK]
- Thinking {@html} escapes HTML instead of rendering it
- Confusing {@html} with creating new elements
- Assuming {@html} comments out code
htmlContent inside a Svelte component?Solution
Step 1: Recall correct {@html} syntax
The correct syntax is {@html variableName} without parentheses or block tags.Step 2: Check each option
<div>{htmlContent}</div>renders as plain text, B uses invalid parentheses, D uses wrong block syntax.Final Answer:
<div>{@html htmlContent}</div> -> Option AQuick Check:
Correct {@html} syntax = {@html variable} [OK]
- Adding parentheses around variable in {@html}
- Using block syntax like {#html}{/html}
- Not using {@html} and rendering raw string
<script>
let htmlString = '<strong>Hello</strong> <em>World</em>';
</script>
<div>{@html htmlString}</div>What will be the rendered output in the browser?
Solution
Step 1: Understand {@html} rendering
{@html renders the string as HTML, so tags become real formatting.Step 2: Analyze the string content
The string contains <strong> and <em> tags, so output will be bold and italic text.Final Answer:
<strong>Hello</strong> <em>World</em> (formatted text) -> Option CQuick Check:
HTML string renders as formatted text [OK]
- Expecting tags to show as text instead of formatting
- Assuming plain text output without tags
- Thinking unsafe HTML causes runtime error
<script>
let unsafeHtml = '';
</script>
<div>{@html unsafeHtml}</div>Solution
Step 1: Identify unsafe HTML usage
The string contains an image with an onerror event that runs JavaScript.Step 2: Understand {@html} risks
{@html renders raw HTML, so malicious scripts can run causing XSS security issues.Final Answer:
It can run unsafe scripts and cause security issues (XSS). -> Option AQuick Check:
{@html with unsafe HTML = security risk [OK]
- Thinking Svelte sanitizes HTML automatically
- Assuming syntax error due to quotes inside string
- Believing image won't display due to src
Solution
Step 1: Understand risks of raw {@html}
Using {@html} directly on user content risks XSS attacks if content is unsafe.Step 2: Best practice for safe HTML rendering
Sanitize user content to remove dangerous tags/scripts, then render with {@html} for formatting.Final Answer:
Sanitize the user content to remove unsafe tags, then use {@html}. -> Option DQuick Check:
Sanitize first, then {@html} = safe rendering [OK]
- Using {@html} directly on raw user input
- Escaping content but losing formatting
- Using <pre> which shows raw text, not formatted HTML
Ready to prove it?
Pass the test and this pattern moves unknown
