Trusted Types Readiness Checker

Scan HTML and JavaScript for the DOM sinks Trusted Types governs - innerHTML, document.write, eval and the rest - and see how much work enforcement would take.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Use the tool

Your code is scanned as text and is never executed, parsed as code, or uploaded.
Or drop a source file here
Up to 10 MB. Read in your browser.

What Trusted Types actually changes

Most defences against cross-site scripting try to make dangerous strings safe. Trusted Types takes the opposite approach: it makes the dangerous functions refuse plain strings altogether. Once enforced, assigning a string to innerHTML throws a TypeError. The only way through is a value produced by a policy you explicitly created and named.

The effect is that every place your application can inject markup or code becomes a place you had to write down. Review stops being a hunt through a codebase and becomes reading a handful of policy definitions. That is the real benefit, and it is why Trusted Types is worth the migration on applications large enough that nobody can hold the whole DOM surface in their head.

What this tool does

It scans what you paste for the sinks Trusted Types governs and tells you how many there are, where they are, which Trusted Type each one needs, and what to do about it. That gives you the size of the migration before you commit to it - which is the question people actually have when they are deciding whether to adopt it.

Your code is never executed

This matters enough to state plainly. The tool reads your source as text and matches patterns against it. It does not run it, does not eval it, and does not parse it into an AST that could be coerced into running. Executing pasted application code inside a visitor's own page would be a far more serious vulnerability than anything this tool could report.

String literals and comments are blanked before matching, so a file that documents “never use innerHTML” does not report itself. Line numbers are preserved through that step, so the positions you get back are real.

And what it therefore cannot see

A text scan cannot follow an alias. If a sink is reached through a variable, a helper function in another module, or a bundled dependency you did not paste, it will not appear. A clean result means “nothing found in this input”, not “nothing to fix”. The readiness figure is an estimate of migration effort, not a security score - treating 100 as “secure” would be exactly the wrong reading.

The sinks, and why each one matters

  • TrustedHTML - innerHTML, outerHTML, insertAdjacentHTML, document.write, iframe.srcdoc. These parse a string as HTML. Any of them reached by attacker-influenced input is DOM-based cross-site scripting.
  • TrustedScript - eval, new Function, and setTimeout or setInterval called with a string. These compile a string into code. new Function is the one people miss, because it does not look like eval.
  • TrustedScriptURL - assigning to script.src, using setAttribute('src', ...) on a script element, or a dynamic import(). These fetch and run remote code.

jQuery is worth a separate mention. $('<div>' + value + '</div>') parses HTML, and jQuery routes it through innerHTML internally - it is the same sink under a different name, which is why this tool reports it.

How to migrate without breaking the site

  1. Scan your front end here to size the work.
  2. Fix what does not need markup at all. A surprising share of innerHTML assignments are setting plain text and should be textContent. These are free wins and reduce the policy surface.
  3. Deploy Content-Security-Policy-Report-Only: require-trusted-types-for 'script'. Nothing breaks; violations are reported. Build the policy with Trusted Types Policy Builder.
  4. Collect reports and read them with CSP Report Analyzer. Expect extension noise here too.
  5. Write a named policy for each remaining legitimate sink, sanitising with a vetted library rather than a regular expression.
  6. Move to enforcement, and add trusted-types to restrict which policy names may be created at all.

Browser support is partial, and that is fine

Trusted Types is supported in Chromium-based browsers and is not yet available everywhere. That does not reduce its value: it is a defence-in-depth measure, and the browsers that do not enforce it simply behave as they did before. More usefully, enforcing it in development catches the sinks for every browser, because the code that would have used them no longer exists.

Frequently asked questions

Does this send my source code anywhere?

No. The scan runs entirely in your browser. There is no upload, no request carrying your code, and nothing written to storage. That is why the tool is limited to text scanning - the alternative would mean executing your code somewhere.

Why did it flag a line that is only a comment?

It should not - comments and string literals are blanked before matching. If you see one, the likely cause is an unterminated string or template literal earlier in the file, which shifts where the scanner believes the string ends.

Is a high readiness figure the same as being secure?

No, and the tool deliberately calls it a readiness estimate rather than a score. It measures how much work Trusted Types adoption would be for the code you pasted. It says nothing about access control, server-side injection, or any code the scan did not see.

Should I use a sanitiser inside my policy?

Yes, and a vetted one - DOMPurify is the usual choice. A policy that returns its input unchanged compiles and satisfies the browser while providing no protection at all, which is the most common way Trusted Types gets adopted without benefit.

References

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.

Rate this tool

Was this tool useful? Your feedback helps us improve it.

No ratings yet — be the first to rate this tool.
Your rating (required)
0 / 2000

Please do not include passwords, payment details or other sensitive information.

Your feedback is sent privately to the A2Z.Tools team and will not be posted publicly.