The script embed

Two lines of HTML put a subscribe form on any page you control. Issue Mint prints them for you in Settings, then the Subscribers tab, with a copy button on each and a preview of the form above them.

The script embed is the version most people want: it takes its colour and its body font from your branding, it confirms a signup in place without leaving the page, and there is nothing to install. For a page that cannot run JavaScript at all, there is the plain HTML form instead.

The snippet

Paste both lines wherever the form should appear.

<div data-issuemint></div>
<script async src="https://app.issuemint.com/embed/v1.js" data-key="pk_3f9c1d7b2a8e4c05d1f6b3a9e7c2"></script>

The div is where the form is built, and it can be any element carrying a data-issuemint attribute. The data-key value is your newsletter’s public key, pk_ followed by 28 characters, and it is the only part of the snippet that differs from anybody else’s. The script is one file with no dependencies and no framework, kept under 10 kB, and it loads async so it never holds up your page.

What the script renders

A label reading Email address, an email field, and a Subscribe button, on one row that wraps on a narrow screen. Underneath sits a status line, hidden until there is something to say, and an off-screen field a reader never sees.

The form is at most 26rem wide, so it fits a sidebar as well as the body of a page. Its accessible name is Subscribe to, followed by your newsletter’s name, so somebody using a screen reader on a page with two forms can tell which is which.

Where the form gets its colour

Colour and font come from the branding you have already set, so a form pasted into your site matches your newsletter website without being told to. The script asks Issue Mint for them as the page loads.

Your primary colour becomes the button background and the focus outline on the field. Your body font is named ahead of a system fallback stack. Both are set in Settings, then Branding, and the answer is cached for five minutes, so a colour you change shows up on your site within five minutes rather than instantly.

Two limits are worth knowing. The script loads no font files, so a body font applies where your page already loads that font and falls back to the system stack otherwise. And your logo is not part of the form.

What a reader sees when it works

The button reads Subscribing… while the request is in flight. Then the form clears and one line appears underneath it, announced politely to a screen reader without stealing focus.

The wording depends on your settings. With double opt-in on, which is the default, the line reads “Almost there - check your inbox to confirm.” With it off, it reads “You’re in. Look out for the next issue.” An address already on your list gets “You’re already subscribed.”

Nothing navigates. The reader stays exactly where they were, which is the whole difference between the script embed and the plain form, and the post-signup redirect setting has no effect here.

What a reader sees when something is wrong

Every failure gets a sentence in the same place as a success, and none of them reveals anything about your list.

Something that is not an address at all is caught before the request is sent, with “Please enter a valid email address.” An address whose domain has no mail server behind it is refused with “We can’t find a mail server for that address - is the part after the @ spelled right?”, which catches a mistyped domain while the reader is still there to fix it. Submitting repeatedly gets “Too many attempts just now. Try again in a minute.”

Two cases deliberately read as ordinary successes. An address that previously complained about your newsletter is dropped and told “Thanks - you’re all set.”, because telling a stranger otherwise would give away who is on your list. And if the account behind the newsletter has no active subscription, signups pause and readers see “Signups are paused right now. Please try again soon.” with no mention of billing, since whose card expired is none of a reader’s business.

Why the script asks nothing of your content security policy

The script uses no inline styles, no eval and no remote fonts, so a site with a strict policy can run it as it comes.

That is stricter than it sounds. A <style> element and a style attribute are both governed by style-src, so on a site sending style-src 'self', which is ordinary on a well-run site, injected styling is silently dropped and the form renders as unstyled browser defaults with its hidden field visible in the page. Issue Mint attaches the stylesheet through CSSOM instead, as a constructable stylesheet, which is not an inline style and applies under that policy.

Safari before 16.4 has no support for that and falls back to a <style> element. Because that is the one combination where the concealment can fail, the script checks whether its CSS applied and removes the hidden field when it did not. A missing field is read as empty by the server, and losing one bot signal is a much better failure than dropping a real person’s signup in silence.

If your site does send a policy, you still name app.issuemint.com in script-src and connect-src, as you would for any third-party script. What you never have to add is 'unsafe-inline' or 'unsafe-eval'.

If no form appears

A broken embed renders nothing and never breaks the page around it, which is deliberate: an unknown key or a failed request is swallowed rather than reported. There is nothing in the console to read, so check the container is present, the key matches the one in Settings exactly, and the script address is the one Issue Mint printed.

Then bear in mind that the script mounts the containers that exist when it runs. A container your own JavaScript adds afterwards is not picked up. Several containers on one page each get their own form, and the stylesheet is attached once.