SRI Hash Generator

Front-end leads pinning CDN scripts, agencies auditing client sites for supply-chain risk, and open-source maintainers publishing release assets all need the same artifact: a correct integrity attribute for a given file. This generator hashes scripts and stylesheets with Web Crypto in the browser, then prints the integrity value plus full script and link tags with the crossorigin pairing already filled in.

SHA-256 SHA-384 SHA-512

Load a file (optional)

File Contents

Integrity Value

Script Tag Snippet

Stylesheet Link Snippet

How Integrity Hashes Are Computed

The browser reads the file bytes exactly as they will be served, runs the selected SHA digest through the Web Crypto API, and encodes the digest as standard Base64. The integrity attribute is the algorithm name, a hyphen, and that Base64 string. When the page loads a tagged resource, the browser re-hashes the response and compares it before the script executes or the stylesheet applies.

Pasted text is converted to bytes with the UTF-8 encoding, so whitespace and line endings count. A file loaded through the picker is hashed from its raw bytes, which matches what a CDN will transmit. The generator also prints script and link tags that already include crossorigin="anonymous", because a missing crossorigin attribute silently disables the verification for cross-origin requests.

Choosing an algorithm

SHA-384 is the common default: every current browser supports it, and the hash length is far beyond what collision attacks can reach. SHA-512 costs a few extra characters in the attribute for a longer digest, and SHA-256 keeps the attribute shortest while still being acceptable to the specification. MD5 and SHA-1 never appear here because browsers reject them.

Byte-level accuracy

A single trailing newline changes the digest. Always hash the artifact that the URL actually serves: the minified production file, not a development copy. If your pipeline rewrites files during upload, compute the hash after that rewrite, or the browser will refuse the resource even though the source you hashed looks identical.

Before and after: adding integrity to a CDN script

Before (unverified)

<script src="https://cdn.example.com/lib.min.js"></script>

After (with integrity)

<script
  src="https://cdn.example.com/lib.min.js"
  integrity="sha384-BYm8X3pK0vH9Q4qJ0fT1cPzqN2xQ=="
  crossorigin="anonymous"></script>

Use Cases

Developer	Production	Workflow
Pin a vendor widget script against CDN tampering	Lock third-party analytics bytes for regulated sites	Generate hashes during release, inject via template
Verify a self-hosted bundle matches the build output	Audit client HTML for missing integrity attributes	Add integrity to a design-system stylesheet CDN path
Compare SHA-384 values across two mirror hosts	Document supply-chain controls for a security review	Store integrity strings next to version pins in config

Common Mistakes and Troubleshooting

The usual failure is hashing a development file while the page loads a different build. Compare the URL in the tag with the file you hashed, character by character. The second is forgetting crossorigin; the network tab then shows the request in no-cors mode and the integrity check never runs against the body. The third is leaving an old integrity value after a deploy, which makes the console report an integrity violation and skip the script entirely.

Line-ending normalization applied by Git on Windows can change bytes between machines. Configure the repository to keep LF endings for published assets, or hash the file produced by CI rather than a local checkout. Inline event handlers and inline scripts cannot use the integrity attribute; move them into external files if they need pinning.

Best Practices for Integrity Attributes

Generate integrity values in the same pipeline step that publishes the asset, and write them into the HTML template automatically so humans never hand-copy digests. Keep crossorigin="anonymous" on every tagged resource, and prefer self-hosting when you control the bytes end to end. For vendor scripts, subscribe to release notes and regenerate the hash when the vendor ships a new version.

List several digests only when you must support very old browsers; on current browsers a single SHA-384 value is enough. Monitor the console during deployments, because an integrity failure is silent to users but obvious in the network log. Pair SRI with a strict Content Security Policy so an attacker who bypasses one control still faces the other.

SRI Hash Generator FAQ

What is Subresource Integrity and when do browsers enforce it?

Subresource Integrity, abbreviated SRI, is a browser mechanism that lets a page pin the exact content of a third-party script or stylesheet. When an integrity attribute is present, the browser hashes the downloaded file and refuses to execute or apply it if the digest does not match. Browsers enforce the check whenever the attribute is present, which makes it a practical defense against a CDN or host serving altered files.

Which hash algorithms are acceptable for SRI?

The SRI specification accepts SHA-256, SHA-384, and SHA-512. SHA-1 and MD5 are rejected by browsers even though older documentation occasionally mentions them. When several digests are listed, the browser picks the strongest one it supports, so listing multiple values is safe but usually unnecessary on modern browsers.

Why does the crossorigin attribute matter next to integrity?

Cross-origin script and stylesheet requests must go through CORS for the integrity check to run against the response body. Without a crossorigin attribute, the browser fetches the file in no-cors mode and cannot verify the hash. The standard pairing is crossorigin="anonymous" on the same tag as the integrity value.

Does this tool upload my file to compute the hash?

No. The page reads the file with the local File API or hashes pasted text with Web Crypto, both inside the tab. Nothing is sent to a server, so proprietary bundles and unreleased assets stay on your machine. There is no account, no history, and no network call in the hashing path.

Why does my SRI attribute break after every deploy?

If your build rewrites bundle contents on each deploy, the hash changes every time, and a hard-coded integrity value will block the new file. Generate the hash as part of the release pipeline and inject it into the HTML template, or drop the integrity attribute for assets you already control end to end and keep it for third-party CDNs only.

Can I use SRI for fonts and images?

Browsers apply integrity checks to script, stylesheet, and worker fetches. Images and fonts loaded through CSS are not hashed by the integrity attribute, so font files and picture assets need different protections such as signed URLs or same-origin hosting. Keep SRI focused on executable and rendering-critical code.

How do integrity hashes interact with CDNs and caching?

The hash covers response bytes, not URLs, so a CDN that injects extra whitespace or transforms JavaScript will fail the check even when the logical code is identical. Disable minification differences by hashing the exact bytes the CDN serves, typically by generating the hash from the published artifact rather than a local pre-processed copy.