iframe sandbox attribute: build it, and read what it actually does

What is the iframe sandbox attribute?

The sandbox attribute puts an iframe's content under a set of extra restrictions. Add it with no value and the framed page gets the strictest treatment there is: scripts do not run, forms do not submit, popups and modal dialogs are blocked, and the content is treated as coming from a unique opaque origin, so it cannot reach anything of yours. Every token you then add gives one of those abilities back.

There are exactly thirteen tokens, and the HTML Standard lists them in one sentence. That matters more than it sounds: browsers ignore attribute values they do not recognise, so a plausible-looking invention grants nothing at all and reports nothing. The value is also an unordered set of unique, ASCII case-insensitive tokens, which means order never matters, ALLOW-SCRIPTS is the same as allow-scripts, and writing a token twice is non-conforming even though it changes nothing.

This builder ticks the tokens, writes the attribute, and then reads the combination back to you — which is the part the checkbox lists elsewhere leave out, because several of the rules are about tokens interacting rather than about tokens individually.

How to use it

1. Tick the abilities the framed content genuinely needs. Each token carries a one-line description of what it re-enables, and — once the page has loaded — a note saying whether your own browser recognises it. The sample buttons load five real cases, including the specification's own worked example.
2. Say where the framed page comes from. Same origin, a different origin, or you cannot promise. This is the question that decides whether the famous allow-scripts plus allow-same-origin warning applies to you, and it is the one thing a validator cannot know.
3. Read the findings, then copy the tag. Findings come in four kinds: markup that does not conform, a way out of the sandbox, tokens that do nothing in this combination, and plain notes. If your iframe sits inside another sandboxed frame, paste that frame's attribute into the nesting box to see what actually survives.

The warning everyone repeats, and the clause they drop

The advice you will have heard is: never set allow-scripts and allow-same-origin together. What the standard actually says is that setting both "when the embedded page has the same origin as the page containing the iframe allows the embedded page to simply remove the sandbox attribute and then reload itself, effectively breaking out of the sandbox altogether".

The middle clause is doing the work. The escape is not magic — it is that same-origin script inside the frame can reach into the document that contains it, delete the attribute, and reload. A cross-origin page cannot touch that document at all, so it has no way to perform the trick. The specification's own worked example is an iframe with sandbox set to allow-same-origin, allow-forms and allow-scripts around a third-party map, and it describes that sandbox as "still useful" because popups and plugins remain blocked.

So the honest rule is narrower and more useful than the folk version: the pair is an escape hatch when you are framing something you serve yourself, and a reasonable configuration when you are framing someone else's origin. If you cannot promise which — a redirect can send a cross-origin URL somewhere same-origin — then you should assume the escape is available, which is exactly why the W3C validator warns about the pair unconditionally. It is a sound default rather than a statement about your case.

The rules a checkbox list will not tell you

Two combinations are non-conforming markup. allow-top-navigation and allow-top-navigation-by-user-activation must not both be specified, because it is redundant — only the unconditional one has any effect. And allow-top-navigation-to-custom-protocols must not be specified alongside allow-top-navigation or allow-popups, for the same reason. Posting both cases to the W3C's Nu validator, it reports the first as an error and says nothing at all about the second, in either spelling — so one of the two rules is not enforced by the tool most people would check with.

Two tokens can also be completely inert. allow-modals does nothing on its own: the standard says alert, confirm and prompt need both allow-modals and allow-same-origin, and the loaded URL has to be same-origin with the top-level page. allow-popups-to-escape-sandbox governs what a window the content opens inherits, so without allow-popups there is no window for it to govern. Neither is an error, so no validator mentions them — you simply get a token that reads as though it did something.

Nesting only ever tightens. The specification works an example where a page frames another with allow-same-origin and allow-forms, and that frame in turn frames a third with allow-scripts: the innermost page gets nothing, because "the iframe in A has scripts disabled, and this overrides the allow-scripts keyword set on the iframe in B". An inner frame can narrow what it was given; it can never hand back something an outer frame withheld.

Finally, the flags latch when the frame navigates. "These flags only take effect when the content navigable of the iframe element is navigated. Removing them, or removing the entire sandbox attribute, has no effect on an already-loaded page." Changing the attribute from script does nothing until something reloads, which is why the standard calls doing so ill-advised.

Honest limitations

This tool reads an attribute; it does not audit a page. It cannot see your Content-Security-Policy, which can impose sandboxing of its own through the sandbox directive, and it cannot see the allow attribute, which is a separate mechanism governing permissions rather than restrictions. It also takes your word about the framed page's origin, because that is the only way anyone could know it in advance.

The per-token support note comes from asking your browser directly. The standard defines the supported tokens for this attribute as the allowed values "and supported by the user agent", which is what makes the question answerable at all — but it reports what the browser will parse, not what it will honour, and a very old engine that exposes no supported-token list at all simply answers nothing.

One thing worth stating plainly: a sandbox is not a substitute for not serving hostile content from your own origin. The specification says so in the same section, and the reason is that an attacker who can persuade someone to open the framed URL directly gets it unsandboxed, in your origin, with no iframe involved.

Why is it free?

It is a set of thirteen strings and a handful of rules, and your browser does all of it as you tick boxes. No server is involved, so there is nothing to meter and no account to create.

Nothing is uploaded. The attribute you build stays in this tab.