Build a Subresource Integrity attribute, with more than one hash if you want, and check an existing one against the file it is meant to pin.
Initializing in your browser…
Build a Content Security Policy and see what a browser will actually apply, including the CSP3 rules that silently discard what you wrote.
Generate passwords from the Web Crypto generator by rejection sampling, with the entropy stated exactly from the alphabet, the cost of every rule computed, and crack times against four named attacker models
Design a CSS button and see every state measured against WCAG on the page colour you name: resting, hover, active, focus and disabled, plus the focus ring and the border.
You inherited a page that pins a CDN script with an integrity attribute, and you want to know whether that attribute is actually protecting anything.
The attribute already on the page
integrity="sha1-oqVuAfXRKap7fdgcCY5uykM6"
What the tool says about it, and what it gives you instead
sha1 (no algorithm a browser accepts)
"sha1" is not one of the three algorithms the specification
defines (sha256, sha384, sha512). A browser ignores it entirely,
which means the resource loads unchecked rather than being blocked.
No token in this attribute is usable. A browser treats that as no
integrity metadata at all and loads the resource WITHOUT checking
it, rather than blocking it.
For the real 73-byte file, hashed here:
sha256-VgkdzYx/A2VEtCY/9DkD+hzKpkKKVXLlH+Ku9ZERRIA=
sha384-jBQg88Ba8MM5HFTIBo9kQdk/+r8lnyrF0F+ttSYOI1/0aSNsJm9rU4fFqcCfkrRk
sha512-DDTVieOSTqZ/gnmfB72B3D1LR1W2OHgo5N6MW49VsW0dv3T/HFMhEo7gaE68LCgy
UrhWSlE6kfYsOSo40ZWWpA==
<script src="https://cdn.example.com/lib@1.2.3/dist/lib.min.js"
integrity="sha384-jBQg88Ba8MM5HFTIBo9kQdk/+r8lnyrF0F+ttSYOI1/0aSNsJm9rU4fFqcCfkrRk"
crossorigin="anonymous"></script>The sha1 attribute is worse than no attribute, because it looks like one. The Subresource Integrity specification defines exactly three algorithms, and a value naming any other is not a failed check: it is no metadata at all, and the resource then loads without being checked while the attribute sits in the HTML implying otherwise. The project tests confirm this against Chrome rather than against the prose, by serving a page under an sha1-only attribute and watching the script run.
The replacement values are the raw digest bytes in standard base64, which is why they carry + and / and end in =, and why they look nothing like the hex sha384sum prints. Each was checked against the recipe the specification itself gives, openssl dgst -sha384 -binary FILE | openssl base64 -A, on the same 73-byte file.
Two details in the tag matter as much as the hash. The URL is the real one, so the element can be pasted as it stands. And crossorigin="anonymous" is there because integrity on a cross-origin resource requires a CORS-enabled fetch; leave it off and the load fails with an error naming CORS and never mentioning integrity, which is the single most confusing way this goes wrong.
One more thing the tool will tell you and most will not: if you put all three hashes above into one attribute, a browser checks only the sha512 one. It finds the strongest algorithm present and ignores the rest, so a weaker hash alongside a stronger one is decoration. Where two hashes genuinely help is when they are the same algorithm, covering two versions of a file during a rolling deployment.
Generate a Subresource Integrity attribute for a script or stylesheet, with one hash or several, and get the element to paste with your real URL and the crossorigin attribute already in it. It also reads an existing attribute back and tells you whether it matches the file, and whether a browser would honour it at all.
An integrity attribute pins the exact bytes of a script or stylesheet, so a compromised CDN or a changed file makes the browser refuse to run it. The value is the algorithm name, a hyphen, and the raw digest in standard base64, which is why it looks like sha384-jBQg88Ba... and not the 96 hex characters sha384sum prints. The digests here come from the same module the hash and checksum tools use, which is checked against node:crypto and the openssl binary, and every result is checked again in the project tests against the recipe the specification itself gives: openssl dgst -sha384 -binary FILE | openssl base64 -A.
The attribute can carry more than one hash, separated by whitespace, and this tool will produce them. What a browser does with several is worth knowing because it is not what people expect: it finds the strongest algorithm present and checks only the entries using that one, ignoring the rest entirely. So adding sha256 alongside sha384 cannot weaken the attribute, and cannot strengthen it either. Where several hashes genuinely help is when they are the SAME algorithm: two sha384 entries let one attribute cover two versions of a file during a rolling deployment, and the browser passes if either matches. Both behaviours are checked in the project tests by serving a real page under the attribute and seeing whether Chrome runs the script, rather than by reading the specification.
The tool also reads an existing attribute back, which is the half most generators do not offer. It shows each token, marks the one a browser will actually check, and accepts the reserved ?option suffix the grammar allows after a hash, which a stricter parser would reject. It names the failures that are otherwise silent: base64url where standard base64 is required (- and _ instead of + and /), a digest of the wrong length for the algorithm named, and, worst of all, an algorithm the specification does not define. sha1 and md5 are not valid SRI algorithms, and an attribute containing only those is treated as having no integrity metadata at all, which means the browser loads the resource WITHOUT checking it rather than blocking it. That is a security control that looks present and is not, and the tool says so in as many words.
Five elements can be built, with the URL you gave actually in them rather than a placeholder: a classic script, a module script, a stylesheet, and preload links for either. The crossorigin attribute is always present and is switchable between anonymous and use-credentials, because integrity on a cross-origin resource requires a CORS-enabled fetch: leave it off and the load fails with an error naming CORS and never mentioning integrity, which is the single most confusing way this goes wrong. The tool says that, warns about an http:// subresource being blocked as mixed content before integrity is ever considered, notes that a preload and the element that uses it must carry the same value, and points out that because the attribute pins exact bytes the URL has to name a fixed version rather than a moving tag.
Input is a file, a URL, or pasted text. Fetching a URL is subject to the same-origin policy, so a CDN that does not send Access-Control-Allow-Origin cannot be read by this page at all; when that happens the tool says what happened and that downloading the file and dropping it in gives an identical digest. The URL is used in the tag whether or not it could be fetched. Everything runs in the browser and nothing is uploaded.
Hash the exact file your page loads and paste the element, so a compromised CDN cannot swap the script under you.
Two hashes of the same algorithm in one attribute cover two versions of a file at once, and the browser passes if either matches.
Paste an existing integrity value and find out whether it is even valid. An attribute naming sha1 provides no protection at all while looking like it does.
Check the current file against the attribute. The tool prints the digest the file actually has, so you can see whether the file changed or the attribute was always wrong.
sha384 is the usual choice and what most CDNs publish. sha256 and sha512 are equally valid. Turning on more than one is allowed but does less than it looks: a browser checks only the strongest algorithm present and ignores the others.
Because the value is the raw digest bytes in base64, not hex. The equivalent command is openssl dgst -sha384 -binary FILE | openssl base64 -A, which the tool prints next to the result.
Yes, separated by whitespace. A browser takes the strongest algorithm present and checks only those entries, passing if any one of them matches. Two entries of the SAME algorithm is the genuinely useful case: it covers two file versions during a deployment.
That is the usual failure. Integrity on a cross-origin resource requires a CORS-enabled fetch, which is what the crossorigin attribute asks for, and the server must send Access-Control-Allow-Origin. Without both, the browser never gets to the integrity check and reports the CORS failure instead.
The same-origin policy. This page can only read a URL whose server sends Access-Control-Allow-Origin, and many CDNs do not send it for a plain fetch. Download the file and drop it in; the digest is identical either way, and the URL you typed still goes into the tag.
No, and the consequence is worse than a rejection. The specification defines only sha256, sha384 and sha512. An attribute containing only sha1 has no valid metadata, and a browser then loads the resource WITHOUT checking it rather than blocking it, so the protection looks present and is not.
You can hash any file here, but integrity is only honoured on script and link elements. There is no way to pin an img or a font loaded from CSS.
File and pasted-code hashing happen entirely in your browser. URL mode fetches the file directly from the host you enter, so that host sees the request; the downloaded bytes are hashed locally.