# Install OptinStack on your site > Add the OptinStack script tag, load it without slowing your page, and confirm the consent banner renders. Author: OptinStack Team Published: 2026-06-28 Page: https://community.optinstack.com/articles/install-optinstack-on-your-site Markdown: https://community.optinstack.com/llms.md/articles/install-optinstack-on-your-site OptinStack ships as a single script tag\. Place it as early as possible in your page head so it can block known trackers before they load\. Once it loads, it fetches your project configuration and renders the consent banner inside a Shadow DOM, so the component is isolated from most host\-page CSS\. This guide walks through adding the tag, placing it for the strongest enforcement, and verifying the banner appears\. ## 1\. Copy your project snippet In your OptinStack dashboard, open **Implementation** for the project you want to install and copy the snippet from the Script Installation card\. The snippet already contains your project ID, so it works as\-is on any domain you have added to that project\. > **Tip:** Add every domain you operate under the same project. One snippet, one project, many domains. Subdomains count as separate domains for billing and scanning. ## 2\. Add the script tag Paste the snippet into the `` of every page where you want the banner to appear\. Place it as the first child of the head, before any third\-party scripts you want consent to govern\. The browser parses a plain script synchronously, which gives OptinStack its earliest chance to install blocking before later trackers run\. _OptinStack install tag (stable channel, auto-update)_ ```html ``` ## 3\. Verify the banner Load your site in a fresh browser session \(or an incognito window\) and confirm the banner appears\. The banner renders once per visitor until they make a choice\. If it does not appear, check that the project ID matches and that the current domain is added to the project\. > **Warning:** Always test in a session with no prior consent. If you already accepted, the banner will not re-show until consent expires or is reset. ### Does the script slow down my page? OptinStack is a plain synchronous script, so the browser parses it as the page loads. Placing it first in the head lets it install blocking before other trackers run. The banner itself renders inside an isolated Shadow DOM and does not interfere with your page styles. ### Where should I place the tag? Place it as the first child of the on every page where the banner should appear, before any third-party scripts you want consent to govern. A plain synchronous script placed first gives OptinStack the earliest chance to block known trackers. ### Do I need a different snippet per domain? No. One project snippet works on every domain added to that project. Add each domain in the dashboard so OptinStack recognizes it. ## Pinned runtime with SRI \(Enterprise\) Standard installs follow the stable channel and receive runtime updates automatically\. Enterprise and internal beta projects can instead pin the runtime to an immutable version URL and protect it with Subresource Integrity\. Pinned installs are reviewable and tamper\-evident, but they do not receive automatic runtime hotfixes: to pick up runtime code changes, select a newer pinned version and republish\. _Pinned runtime tag with root SRI_ ```html ``` Pinning only freezes the executable runtime bytes\. Banner configuration, tracker inventory, region context, and translations still load as JSON data, so publishing banner copy, scanning, or translating your preferences dialog does not change the pinned runtime bytes and never requires re\-issuing the SRI hash\. ### Configure a pinned install from the dashboard 1. Open the project and go to Settings → Runtime\. 1. Under Pinned runtime version, choose the immutable release you want to install\. Enabling SRI requires a pinned version\. 1. Turn on Root runtime SRI\. The dashboard shows the root and banner SRI hashes for the selected release so you can copy them into a security review before publishing\. 1. Copy the generated pinned snippet from Implementation and install it in your site head exactly as provided\. To receive runtime code updates, return to Settings → Runtime, select a newer pinned version, and republish\. Disabling SRI or clearing the pinned version returns the install to the selected channel \(stable by default\)\. ### Verify integrity in production 1. Fetch the versioned manifest\. It lists the optinstack and banner integrity hashes for the release\. _Fetch the release manifest_ ```bash curl -s https://api.optinstack.com/v1/js/runtime/{version}/manifest.json ``` 1. Download both artifacts, compute a `sha384-` hash \(base64 of the SHA\-384 digest\), and compare against the manifest\. The recomputed values must match exactly\. _Recompute SRI from served bytes_ ```bash curl -s https://api.optinstack.com/v1/js/runtime/{version}/optinstack.js \ | openssl dgst -sha384 -binary | base64 # -> sha384-... ``` 1. Confirm the snippet in your page head carries both `integrity` and `crossorigin="anonymous"`\. If either is missing or the bytes do not match, the browser refuses to execute the runtime\. > **Info:** Both the root optinstack.js and the split banner.js are integrity-protected on pinned installs. The runtime reads the banner integrity from the release manifest and applies it when loading banner.js, so you only need to add the root SRI to your snippet. ### Does pinning break automatic updates? It freezes runtime code, not configuration. Banner copy, tracker inventory, region context, and translations continue to update via JSON. To pick up runtime code changes, select a newer pinned version in the dashboard and republish the snippet. ### Why are the root and banner SRI hashes different? They hash different artifacts. optinstack.js is the consent kernel and banner.js is the Shadow DOM UI bundle. Each has its own sha384 hash in the release manifest. The hash for a given artifact only changes when a new runtime release is published.