Professional live HTML/CSS/JS editor and sandboxed preview
Allowing users to write arbitrary HTML and JavaScript and executing it in the browser is the textbook definition of a Cross-Site Scripting (XSS) vulnerability.
If we simply injected your provided code directly into our application's DOM, any malicious JavaScript you wrote could access KaruviLab's local storage, steal cookies, or hijack the entire application.
To prevent this, the preview window uses an <iframe> with a strict sandbox attribute. By default, a sandboxed iframe blocks everything—it cannot run scripts, submit forms, or access the parent window's data.
We selectively re-enable features using flags like allow-scripts (so your JavaScript runs) but we deliberately omit allow-same-origin. This forces the browser to treat the iframe as if it came from a completely different domain (a unique origin), ensuring the code you write has absolutely zero access to our application state.
How do we pass your code into the iframe without sending it to a server? We generate a Blob URL.
Using URL.createObjectURL(new Blob([html], { type: 'text/html' })) creates a temporary, local URL that points directly to the browser's memory. This is significantly faster and more memory-efficient than using a massive Base64 Data URI, especially for large blocks of code.
Why must the preview window for an HTML editor use an iframe with the 'sandbox' attribute?