The first time you need an iframe to render HTML that you already have in memory, you hit a friction point: src wants a URL, but your content might be a string you just generated (a receipt preview, an email template, a Markdown-to-HTML render, a sandboxed widget). You can write a temporary file, spin up an endpoint, or stuff the HTML into a data: URL—but all of those have tradeoffs you feel immediately in debugging, caching, security posture, and developer experience.\n\nThat’s where srcdoc earns its keep. It lets you place the iframe’s document markup directly on the element, so the browser builds a nested browsing context from an HTML string rather than fetching a separate resource. When I’m building previews, isolated widgets, or “render this HTML safely” features, srcdoc is one of the cleanest tools in the HTML toolbox—provided you treat it like a loaded power tool.\n\nI’ll walk you through what srcdoc does, how it interacts with src, the escaping rules that trip people up, how sandbox changes the security model, and a set of practical patterns (plus a few sharp edges) you should know before shipping it.\n\n## What srcdoc really does (and how it interacts with src)\nsrcdoc is an attribute on that contains the HTML markup the iframe should display. Think of it as handing the browser a tiny HTML file inline.\n\nThe key behavior you should internalize:\n\n- If the browser supports srcdoc, it uses srcdoc as the iframe’s document, even if src is also present.\n- If the browser doesn’t support srcdoc, it falls back to src (if present).\n\nThat fallback behavior is the main reason I still set src in many production cases: it’s not just about legacy support; it’s also a convenient place to point to an error page, a “feature not supported” message, or a lightweight placeholder when srcdoc isn’t honored.\n\nHere’s a complete, runnable file that demonstrates the override/fallback relationship (written as an indented code block so it stays valid markdown without fenced code blocks):\n\n \n \n \n \n \n
srcdoc overrides src (when supported)
\n\n
iframe with src + srcdoc
\n <iframe\n title='Inline content'\n src='fallback.html'\n srcdoc='\n \n body{font-family:system-ui;padding:12px}code{background:#f3f3f3;padding:2px 6px;border-radius:6px}\n \n
Rendered from srcdoc
\n
If your browser supports srcdoc, you see this.
\n \n ‘>\n \n
If srcdoc is unsupported, the browser loads fallback.html instead.
\n
\n\n
iframe with src only
\n \n
This one always loads fallback.html.
\n
\n
\n\n
\n
Tip: if you don’t want a network request for the fallback, you can set src to a small local file (or even about:blank in some setups), but be deliberate—see the security section before using that as a default.
\n \n \n\nA detail people miss: srcdoc is not “HTML inside the iframe element.” It’s an attribute value, which means you inherit all the usual attribute encoding concerns. That leads straight to the next section.\n\n### A subtle but important point: “document URL” and why relative links behave strangely\nWhen you load a real page via src, the iframe has a real URL. That URL becomes the base used for relative resources like ./styles.css or ./image.png. With srcdoc, there is no fetched document URL in the normal sense. Practically, this means: relative URLs inside your srcdoc content can be surprising, inconsistent across setups, or just not what you intended.\n\nIf your srcdoc content includes assets, I strongly prefer one of these strategies:\n\n- Use absolute URLs for assets (carefully; see security and privacy sections).\n- Inline critical assets (CSS, tiny images as data URLs) when appropriate.\n- Add a tag in the srcdoc HTML so you control how relative URLs resolve.\n\nExample (also indented):\n\n <iframe\n title='Preview with base'\n srcdoc='\n \n \n \n \n \n 
\n \n ‘>\n \n\nThat said: a tag can also be abused by untrusted HTML (it can rewrite where links and form actions go), so only use it when you fully control the markup, or you strip it during sanitization.\n\n## The escaping rules: quoting, entities, and template literals\nIf you’ve ever tried to paste full HTML into an attribute and watched it break, you already know the issue: srcdoc is text inside quotes, inside an HTML parser. You must avoid ending the attribute early or injecting accidental markup.\n\n### Rule 1: Pick one quote style and stick to it\nIf your iframe attribute uses double quotes, prefer single quotes inside your inline HTML (or vice versa).\n\nExample pattern I use often:\n\n- Outer attribute: double quotes\n- Inner HTML attributes: single quotes\n\n <iframe\n title='Preview'\n srcdoc="\n \n \n
Hello
\n \n ">\n \n\n### Rule 2: Escape what can terminate the attribute\nIf your inline HTML must contain the same quote type as the outer attribute, you must escape it as an HTML entity.\n\n- For an outer double quote: write " inside the srcdoc value.\n- For an outer single quote: write ' (or ', though ' is the safest habit).\n\nIn practice, when I’m generating srcdoc from JavaScript, I try not to depend on “manual” escaping. I either:\n\n- keep the srcdoc document simple enough that I can avoid conflicting quotes, or\n- use a real escaping helper (more on that in a minute), or\n- switch to a Blob URL if the payload is large and quote-heavy.\n\n### Rule 3: Treat as a special hazard\nIf you include in srcdoc, the literal sequence can end the script element during HTML parsing. When you generate script content dynamically, split the string:\n\n const script = ‘console.log(\‘hi\‘)‘;\n\nI’m not recommending lots of inline script in srcdoc—I’m showing the edge case because it shows up in real apps (especially when people paste analytics snippets or templated scripts into HTML strings).\n\n### Rule 4: Consider generating the document differently\nIf your srcdoc content is complex, I usually stop fighting attribute escaping and switch to one of these:\n\n- Build a minimal HTML shell in srcdoc and inject content via postMessage.\n- Use a Blob URL when you want a URL-shaped thing without a server.\n\nHere’s a quick decision table I use in practice:\n\n
Best for
\n
—
\n
srcdoc Small-to-medium HTML previews, deterministic markup, no fetch
\n
src=‘/preview.html‘ Static templates, cacheable resources
\n
src=‘data:text/html,...‘ Tiny payloads, quick experiments
\n
src={URL.createObjectURL(new Blob([...]))} Large markup, less escaping, programmatic generation
revokeObjectURL, origin/security rules \n\nIf you’re using a modern UI framework, I recommend generating srcdoc with a template literal and a small escaping helper rather than concatenating strings.\n\n### A practical escaping approach I actually use\nWhen I must interpolate content into a srcdoc document (especially user-provided text that I want to render as text), I separate two concerns:\n\n1) Escape for HTML text context (so < doesn’t become markup).\n2) Avoid breaking the attribute itself (quotes, etc.).\n\nExample helper for escaping plain text into HTML (not a sanitizer; just text escaping):\n\n function escapeHtmlText(value) {\n return String(value)\n .replaceAll(‘&‘, ‘&‘)\n .replaceAll(‘‘, ‘>‘)\n .replaceAll(‘"‘, ‘"‘)\n .replaceAll("‘", ‘'‘);\n }\n\nThen build a document that mostly avoids quote conflicts by using single quotes inside the HTML.\n\nThe important caveat: escaping text is not sanitizing HTML. If you plan to allow HTML tags, you need sanitization (covered later).\n\n## Security model: sandbox, origin, and why srcdoc is not a free pass\nsrcdoc often gets described as “safer because it’s local,” which can be dangerously misleading.\n\nHere’s the reality I want you to keep in mind:\n\n- An iframe created via srcdoc can still run scripts (unless you restrict it).\n- If you place untrusted HTML into srcdoc without strong restrictions, you’re one bad string away from cross-site scripting in a new outfit.\n\n### The big mental model\nI explain it like this: srcdoc is a delivery method, not a security boundary.\n\nIf the HTML you’re placing into srcdoc is untrusted (user-generated content, third-party snippets, AI-generated HTML you didn’t sanitize), you should treat it like you’re about to innerHTML it into your main page—because in many ways, you are.\n\n### sandbox is the first control you should reach for\nThe sandbox attribute lets you restrict what the iframe content is allowed to do. You can:\n\n- disable script execution\n- prevent form submission\n- block top-level navigation\n- block popups\n- isolate origin (very important)\n\nA practical default for untrusted preview content is:\n\n <iframe\n title='Untrusted preview'\n sandbox\n referrerpolicy='no-referrer'\n srcdoc='
Untrusted content here.
‘>\n \n\nNote: sandbox with no tokens is the strictest setting.\n\n### Be careful with allow-scripts and allow-same-origin\nIf you add allow-scripts, scripts run inside the iframe.\n\nIf you add allow-same-origin, the iframe is treated as same-origin (depending on context), which can allow access between the iframe and the parent if you’ve also allowed scripts.\n\nThe combination sandbox=‘allow-scripts allow-same-origin‘ is commonly used for certain “embedded app” scenarios, but I treat it as a high-risk combination for untrusted HTML because it can collapse the isolation you thought you had.\n\nWhen I need interactivity for untrusted content, I prefer:\n\n- sandbox=‘allow-scripts‘ (without allow-same-origin)\n- communicate via postMessage\n- keep a strict message protocol\n\nHere’s a runnable parent + srcdoc example that uses postMessage with a simple allowlist (still indented code).\n\n \n \n \n \n \n
Controlled communication with a sandboxed srcdoc frame
\n\n \n
\n\n <iframe\n id='frame'\n title='Sandboxed frame'\n sandbox='allow-scripts'\n srcdoc='\n \n \n \n
Frame
\n
This frame can run scripts, but it is sandboxed.
\n \n window.addEventListener("message", (event) => {\n const data = event.data;\n if (!data
data.type !== ‘PONG‘) return;\n log(‘Parent received PONG at ‘ + new Date().toISOString() + ‘ (frame timestamp: ‘ + data.receivedAt + ‘)‘);\n });\n\n pingBtn.addEventListener(‘click‘, () => {\n frame.contentWindow.postMessage({ type: ‘PING‘ }, ‘‘);\n log(‘Parent sent PING‘);\n });\n \n \n \n\nA few security notes I follow in production:\n\n- I validate message shapes strictly (type + expected fields).\n- I avoid exposing privileged APIs to iframe content.\n- If the iframe is not same-origin, I check event.origin where meaningful.\n- I keep the iframe’s capabilities minimal (start with strict sandbox, then add only what you can justify).\n\n### Sanitization: if the HTML is untrusted, sanitize it anyway\nsandbox reduces blast radius; it does not magically make untrusted HTML safe. In real apps, you often still want sanitization to prevent nuisance behavior (unexpected forms, huge images, phishing-like UI) and to avoid relying on a single control.\n\nIf you’re sanitizing HTML client-side, use a proven sanitizer. Here’s a runnable example using DOMPurify via an ESM CDN (easy to try, but pin versions in real projects).\n\n \n \n \n \n \n
Sanitize untrusted HTML before srcdoc
\n
Try typing something like: <img src=x onerror=alert(1)>
\n\n \n\n \n\n <iframe id='preview' title='Preview' sandbox srcdoc='
Click Render
‘>\n\n \n import DOMPurify from ‘https://cdn.jsdelivr.net/npm/[email protected]/dist/purify.es.mjs‘;\n\n const input = document.getElementById(‘input‘);\n const renderBtn = document.getElementById(‘render‘);\n const preview = document.getElementById(‘preview‘);\n\n renderBtn.addEventListener(‘click‘, () => {\n const clean = DOMPurify.sanitize(input.value, {\n USE_PROFILES: { html: true }\n });\n\n preview.srcdoc = \n \n \n \n \n body{font-family:system-ui;padding:12px}img{max-width:100%}\n \n ${clean}\n ;\n });\n \n \n \n\nIf you’re building a serious product surface where users can paste rich HTML, you should also enforce server-side controls (policy, auditing, rate limits) and consider CSP strategies, but sandbox + sanitization is the baseline I recommend.\n\n### A CSP note I wish more people knew\nA sandboxed iframe is powerful, but it’s not the only lever. If you control the srcdoc document, you can also include a Content Security Policy inside it (often via a tag). This can help you: block scripts entirely, prevent network calls, or constrain where images/styles can load from.\n\nThere are nuances and browser behaviors to be aware of, and I don’t rely on this alone for untrusted content—but as a defense-in-depth layer, it’s useful when you’re building a preview surface you truly want to lock down.\n\n## Real-world patterns: previews, emails, widgets, and docs\nI rarely use srcdoc for “regular pages.” I use it when the content is:\n\n- generated dynamically\n- short-lived\n- best rendered in isolation\n\nHere are patterns that have held up well for me.\n\n### Pattern 1: A printable invoice/receipt preview\nYou want your main page to keep its layout, fonts, and scripts, while the preview behaves like a mini document with its own CSS.\n\nI usually do:\n\n- strict sandbox (often no scripts at all)\n- inline minimal CSS in the iframe document\n- a print button that calls frame.contentWindow.print() only when it’s safe and same-origin rules allow it\n\nIf you do need printing, you might set sandbox=‘allow-modals‘ and avoid scripts in the frame entirely. If you can’t meet those constraints, don’t fight it—render a dedicated preview route with src.\n\nA practical printing-friendly approach is: keep the frame same-origin and script-free, and trigger print from the parent. In a typical app, that looks like:\n\n- frame content is plain HTML + CSS\n- parent UI triggers print()\n- you provide “print CSS” inside the srcdoc document (page margins, hiding buttons, etc.)\n\n### Pattern 2: Rendering Markdown to HTML without polluting the host page\nA Markdown renderer typically outputs HTML. Putting that HTML in your main DOM can break styling or accidentally inherit site CSS. In a srcdoc frame you can reset styling and get consistent rendering.\n\nI often include a small CSS reset in the iframe document:\n\n- body { max-width: 70ch; margin: 0 auto; }\n- set line-height and font-family\n- style headings and code blocks\n\nA detail that matters: many sites have aggressive global CSS (e.g., img { max-width: 100% }, * { box-sizing: border-box }, custom fonts, etc.). An iframe is a clean way to avoid your preview being unintentionally “themed” by your product’s stylesheet.\n\n### Pattern 3: Third-party widgets (that you still want to fence in)\nIf you must embed third-party markup/scripts, srcdoc can be a packaging layer, but I prefer src when the third party expects a real URL and predictable navigation context.\n\nWhen I do use srcdoc here, I keep it minimal: a bootstrap HTML shell with a strict sandbox, and then I load the third-party script only if I can constrain it (via sandbox, allow permissions, and ideally CSP). If I can’t constrain it, I assume it can misbehave.\n\n### Pattern 4: Email template previews\nEmail HTML is its own weird ecosystem. A lot of it relies on table layouts, inline styles, and conditional comments. Rendering it in your main page can wreak havoc on your CSS assumptions, but rendering it in an iframe is usually stable.\n\nI like srcdoc for this because:\n\n- you can render instantly without a server round trip\n- you can show multiple variants side-by-side (desktop vs mobile width)\n- you can freeze the preview to a known viewport (set iframe width/height)\n\nOne caveat: what renders in a browser is not the same as what renders in email clients. I treat browser preview as a convenience, not a validation tool.\n\n### Pattern 5: Documentation and component playgrounds\nIf you’re building an internal “component preview” tool, srcdoc is a fast way to render a component output isolated from the host app. The trick is deciding how “real” you want that environment to be.\n\n- For static examples: pure srcdoc with no scripts is perfect.\n- For interactive examples: I either allow scripts but keep origin isolated, or I switch to a dedicated route loaded via src so I can manage dependencies more cleanly.\n\n## When I use srcdoc (and when I do not)\nChoosing srcdoc is less about “can I?” and more about “should I?”. Here’s how I decide.\n\n### I reach for srcdoc when…\n- I’m rendering HTML I already have as a string (generated content).\n- I want isolation from parent CSS and layout.\n- I want quick previews without network requests.\n- I can keep the document small-to-medium in size.\n- I can lock it down with sandbox (and ideally sanitization).\n\n### I avoid srcdoc when…\n- The content needs a stable URL (routing, history navigation, deep linking).\n- The content loads many assets with relative URLs and I don’t want to manage or absolute paths.\n- I need serious interactivity with shared state and rich dependencies.\n- The HTML is very large or frequently updated (performance and memory churn).\n- I’m embedding truly untrusted third-party applications that need broad permissions.\n\nA quick “gut check” question I ask myself:\n\n> If this iframe were compromised, what’s the worst it can do to my users?\n\nIf the answer is “a lot,” then srcdoc plus a loose sandbox is not the plan. I tighten the sandbox, sanitize hard, or move the render surface to a safer architecture (dedicated origin or separate domain).\n\n## Performance considerations: what gets faster, what can get slower\nPeople often assume srcdoc is always faster because it avoids a fetch. Sometimes it is, but there are tradeoffs. Here’s how it typically shakes out in real apps.\n\n### Where srcdoc can be faster\n- No network request: fewer round trips, less server work.\n- No caching complexity: the content is already in memory.\n- Predictable render path for small documents: the browser parses the markup and paints.\n\nIn many UI-driven apps (admin tools, editors, preview panes), those benefits are exactly what you want.\n\n### Where srcdoc can be slower (or at least more expensive)\n- Large HTML strings: parsing a big document repeatedly can become noticeable.\n- Frequent updates: repeatedly setting iframe.srcdoc = ... can churn memory and re-run layout/paint inside the frame.\n- Heavy inline styles/scripts: every update repeats work unless you architect around it.\n\nA pattern I use to keep previews smooth: update less.\n\n- Debounce updates from typing (e.g., 150–300ms).\n- Only re-render the iframe when the input actually changes.\n- Prefer incremental messaging (postMessage) for small updates rather than full document replacement.\n\n### loading=‘lazy‘ and perceived performance\nIf the iframe is below the fold, add loading=‘lazy‘. It doesn’t change the fundamental cost of parsing the srcdoc document, but it can improve the user experience by deferring that cost until the user scrolls.\n\nExample:\n\n <iframe\n title='Below fold preview'\n loading='lazy'\n sandbox\n srcdoc='…‘>\n \n\n### Resizing and layout cost\nA classic srcdoc use case is a preview that should “hug” its content. The naive approach is to measure scrollHeight and resize the iframe. That works, but be careful: reading layout metrics repeatedly can trigger forced reflow.\n\nIf you control the iframe content and it’s same-origin (or you can message), an efficient pattern is:\n\n- iframe posts its height to the parent after render\n- parent sets iframe height\n- iframe posts again if content changes\n\nThis keeps layout reads mostly inside the iframe, and the parent only applies the result.\n\n## Common pitfalls (the stuff that burns time)\nThese are the mistakes I see repeatedly—and the quick fixes.\n\n### Pitfall 1: Broken HTML because the attribute ended early\nSymptom: the iframe shows nothing, or DevTools shows a mangled element.\n\nCause: unescaped quotes or > characters in the attribute value.\n\nFix: adopt a consistent quoting strategy and escape where necessary. If it’s still painful, stop and switch to Blob URLs.\n\n### Pitfall 2: “Why aren’t my styles applying?”\nSymptom: preview looks unstyled, or styles partially apply.\n\nCause: your srcdoc document is missing a proper HTML structure, or your CSS is being overridden by inline styles in the content, or you forgot a meta charset and special characters broke parsing.\n\nFix: always include a minimal complete document: , , and a small CSS baseline.\n\n### Pitfall 3: “Why do my relative links or images fail?”\nSymptom: images 404, CSS doesn’t load, links go to unexpected places.\n\nCause: the iframe doesn’t have the base URL you assumed.\n\nFix: use absolute URLs, inline assets, or a tag (only for trusted content).\n\n### Pitfall 4: Sandbox tokens that quietly disable what you need\nSymptom: forms don’t submit, downloads don’t work, scripts don’t run, popups fail.\n\nCause: the default sandbox disables a lot.\n\nFix: add only the token you need—one at a time—and document why. Example progression I actually use:\n\n- start: sandbox\n- need scripts: sandbox=‘allow-scripts‘\n- need a modal: add allow-modals\n- need form submission: add allow-forms\n\nI avoid “kitchen sink” sandboxes that include everything “just in case.”\n\n### Pitfall 5: Assuming event.origin always helps in postMessage\nWhen you sandbox an iframe without allow-same-origin, the frame’s origin becomes opaque. That means event.origin checks can be less informative than you expect.\n\nFix: validate message structure strictly, and consider using a capability token in your message protocol (a random nonce that the parent injects and expects back). Also: don’t treat postMessage as an authentication mechanism; treat it as a transport with validation.\n\n## Alternative approaches (and why you might pick them)\nSometimes srcdoc is the right tool. Sometimes it’s the second-best tool that still works. Here are the main alternatives and the practical reasons to choose them.\n\n### Alternative 1: Blob URLs (my favorite “escape hatch”)\nIf you want “inline HTML” without attribute-escaping pain, Blob URLs are great. You generate a Blob from your HTML string, then set iframe.src to the object URL.\n\nPros:\n- No attribute escaping for the HTML content itself.\n- Handles large documents well.\n- Feels like a normal URL load, which can make debugging easier.\n\nCons:\n- You must revoke URLs (URL.revokeObjectURL) or you’ll leak memory.\n- Origin and access rules differ from a normal same-origin page.\n- Still not a security boundary; you still need sandbox/sanitization for untrusted HTML.\n\n### Alternative 2: data:text/html,...\nThis can work for tiny payloads or quick prototypes. But in production, I avoid it for anything substantial because it gets painful to encode, and you can run into length limits or debugging misery.\n\n### Alternative 3: A dedicated preview route loaded via src\nWhen you need a stable environment—assets, routing, shared code, analytics, printing, consistent base URL—this is often the cleanest.\n\nYou pay a network request (or at least a navigation), but you gain:\n- a real URL\n- server-side policy and logging\n- better caching options\n- less string-escaping complexity\n\n### Alternative 4: Shadow DOM / isolated container (not an iframe)\nIf your main reason is “avoid CSS collisions,” sometimes Shadow DOM is enough. It doesn’t provide the same security boundary as an iframe sandbox, but it can isolate styles and markup.\n\nI treat it as a styling tool, not a security tool. For untrusted HTML, I still prefer a sandboxed iframe.\n\n## Practical production checklist (what I verify before shipping)\nWhen I ship a srcdoc feature, I run through a checklist like this:\n\n1) Trust boundary: Is the HTML fully trusted, partially trusted, or untrusted?\n2) Sandbox default: Start with sandbox (no tokens) and add only what’s needed.\n3) Sanitization: If the HTML is untrusted, sanitize it. If it’s user-generated but “mostly trusted,” sanitize it anyway (defense in depth).\n4) Referrer policy: Set referrerpolicy=‘no-referrer‘ or a stricter option that matches the product’s privacy requirements.\n5) Permissions: If you use the allow attribute (camera, microphone, etc.), be explicit and restrictive.\n6) Asset strategy: Avoid relative asset URLs, or control them with (trusted content only).\n7) Accessibility: Give the iframe a meaningful title, ensure focus behavior is reasonable, and don’t trap keyboard users.\n8) Update strategy: Debounce live updates; avoid replacing the full document unnecessarily.\n9) Observability: Log preview rendering failures (sanitizer errors, parsing issues) in a way you can debug without capturing sensitive content.\n\n## Accessibility and UX notes I bake in early\nI know this section isn’t glamorous, but it’s the difference between a preview that “works on my machine” and a preview that works for real users.\n\n### Always provide a useful title\nScreen readers use the iframe title to describe the frame. “Preview” is better than nothing, but “Invoice preview for INV-20491” is better than “Preview.”\n\nExample:\n\n <iframe\n title='Invoice preview (INV-20491)'\n sandbox\n srcdoc='…‘>\n\n### Think about focus and keyboard navigation\nIf your iframe contains interactive controls, keyboard users will tab into it. That can be fine, but be deliberate:\n\n- Does the frame need to be interactive? If not, don’t allow scripts/forms.\n- If it is interactive, provide clear focus styles inside the frame.\n- Consider a “Skip preview” link before the iframe in the parent UI if the preview is large.\n\n### Don’t rely on color alone inside the preview\nIf you’re rendering status labels (paid/unpaid, error/success) inside the srcdoc document, use icons/text, not just red vs green styling.\n\n## Expansion Strategy\nAdd new sections or deepen existing ones with:\n- Deeper code examples: More complete, real-world implementations\n- Edge cases: What breaks and how to handle it\n- Practical scenarios: When to use vs when NOT to use\n- Performance considerations: Before/after comparisons (use ranges, not exact numbers)\n- Common pitfalls: Mistakes developers make and how to avoid them\n- Alternative approaches: Different ways to solve the same problem\n\n## If Relevant to Topic\n- Modern tooling and AI-assisted workflows (for infrastructure/framework topics)\n- Comparison tables for Traditional vs Modern approaches\n- Production considerations: deployment, monitoring, scaling\n\n### A final personal rule of thumb\nIf I can describe the feature as “render some HTML someone gave me,” I assume it’s dangerous until I prove otherwise. With srcdoc, you can build excellent preview and embedding experiences—but the winning move is to pair its convenience with disciplined boundaries: strict sandboxing, thoughtful sanitization, and a deliberate rendering strategy that doesn’t churn the browser on every keystroke.\n\nOnce you treat srcdoc like a power tool instead of a shortcut, it becomes one of the most practical ways to deliver safe, fast, isolated HTML rendering without turning your application into a tangle of temporary files, endpoints, and encoding hacks.
