Paste the exact contents of a script or stylesheet, or pick a file, and get the sha256, sha384, and sha512 integrity values for it. Drop the value into an integrity attribute so the browser refuses any tampered or swapped copy served from a CDN you do not control.
Most pages load some scripts and stylesheets from a host they do not own, often a public CDN. That host is now part of your trust boundary: whatever bytes it sends, the browser runs on your page with the full power of your origin. Subresource Integrity closes that gap. You compute a cryptographic hash of the exact file you reviewed and pin it in an integrity attribute. The browser hashes whatever it actually downloads and runs the file only if the two match, drawing on the behavior defined in the Subresource Integrity specification.
A script you pull from a CDN is a standing invitation. If an attacker reaches that CDN, a popular package, or the build pipeline behind it, they can quietly replace your file with one that reads forms, steals tokens, or rewrites the page. Because the browser trusts code by where it sits in the markup and not by what it contains, a swapped file runs with the same authority as the one you intended. This is the same client side trust surface that makes a stored cross site scripting payload so damaging, except here the injection point is a host you do not even operate.
An integrity value is a label and a base64 digest joined by a dash, like sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC. When the browser fetches a resource that carries an integrity attribute, it computes the same hash over the bytes it received and compares. On a match the file loads. On a mismatch the browser treats the request as a network error and refuses to run the script or apply the stylesheet, so the tampered bytes never execute. You can list more than one hash, separated by spaces, and the browser uses the strongest algorithm it understands.
For a resource loaded from another origin, the browser will only check integrity when the request is made with cross origin credentials mode anonymous, which you opt into with crossorigin="anonymous", and the serving CDN must return the matching CORS headers. Without that pairing the browser cannot read the response bytes to hash them, so it blocks the resource rather than silently skipping the check. That is why every cross origin SRI tag needs the crossorigin attribute, and why a CDN that does not send proper CORS cannot be pinned this way.
SRI proves the file matches the hash you reviewed, nothing more. It is honest to be clear about the edges:
Deciding which third party code is worth loading at all, and how to bound the damage if it turns hostile, is the wider discipline of web application security, and the kind of reasoning an AI security testing approach applies across a whole app rather than one tag at a time.