Burn After Reading

Here is the part no one selling a conversion trick says out loud. I built this last week and I have run zero split tests. I put it on a page that gets close to nobody, on purpose. If a dead page can still pull an email from a stranger, it works anywhere you bolt it on. The two working files are free at the bottom, no email wall. This page shows you the idea and hands you the two files to put it live in about twenty minutes.

The traffic shows up. You wrote the page. Your opt-in box asks for an email. Your reader has no reason to give one, so they scroll past and leave.

A fire effect is fun. Flip one switch and it becomes a conversion mechanic. I keep calling it a theory, because I have not proven it. The logic is why I bet on it.

Most CTAs get ignored. A popup interrupts and gets closed on reflex. Both of them ask. This one does not ask. It takes something away and offers to give it back. Fear of loss moves people harder than the promise of a gain. Almost no marketing gets to pull that lever, because you cannot take back a thing you never handed over. This page hands you the words first. Then it takes them. Then it makes your email the way back. It forces a choice instead of asking for one.

You already know this feeling. Take a toy from a kid who was ignoring it a second ago, and watch the meltdown over the thing they just dropped. We do not want what we hold. We want what got taken. Desire comes from not having it.

I lived the grown-up version last month. Anthropic gave everyone a new model called Fable 5 for free. A few days later they pulled it with no warning. I did not care about that model until it was gone. Then it was the only thing I wanted. It came back, and the wanting stopped the second it did. Same primal wiring, pointed at a page instead of a toy.

A normal opt-in asks you to picture a benefit you might get one day. This one shows you the value, lets you hold it, then takes it. The email is not a request. It is the trade to undo the loss. It is scarcity you can see. It is a deadline that runs while you move, not a fake countdown you have learned to ignore. And the price is one email, the smallest yes there is.

I have not split-tested this yet. My gut says loss beats gain every time. So I am running it in public, where you can watch it work or watch it flop. Here is one I built so you can feel it instead of imagine it.

Live demo, embedded with the exact sandboxed-iframe method the build half below teaches. Codes are made up.

Find your business below and play with that demo. The pattern is the same every time, you point the loss at a different thing.

1. The coupon vault. Show the discount, then hide it. The reader has already seen the value before they pay for it with an email, so you are not selling the idea of a deal, you are revoking a deal they can see.

2. The price reveal. Service businesses bury the price behind "contact us for a quote" and lose the lead in the gap. Show the price, burn it, make "see what it costs" the unlock. The person who burns to see the number was going to ask anyway, except now you have their email instead of an abandoned form.

3. The receipt reveal. The play I would run on my own list: show the exact work behind one real win, then redact the dollar figure until they subscribe. Show the work, gate the number. My bet is that people trade an email for a specific number far faster than for a vague newsletter, and the redaction makes the figure feel earned.

4. The table lottery. Picture a QR code on every table at a bar. Scan it and tonight's prize sits hidden until you drop an email or a number. Every play wins something and no two pulls match. A first-timer pulls one prize and a regular pulls a better one. So the whole table plays to see who pulls the best combo, and every play hands the bar a contact. This is the one I would build first.

One technical note so you do it right: when the reader unlocks, capture the email by sending it to your provider properly, a POST to your list's API or your own serverless function. Do not stuff the address into a URL like ?email=, because URLs get logged in browser history and server logs. Send it in the body of a request, not the address bar.

The two files are free. You can have this live in about twenty minutes. It works on Shopify or WordPress or Webflow or any site that takes an embed. You get eleven costumes, so you can point the destruction at the fear your reader already has. Sold already? Skip to the files ↓

And the fire is just a costume. Same engine underneath, eleven completely different "oh no." The chips at the top of this page switch between them live. Try a few before you read on.

Each is the same engine wearing a different metaphor. The trick is to point the destruction at the exact thing your audience is afraid of.

• Burn - words char to ash. The flagship.
• Spy - black redaction bars slam down like a leaked file. For the gated dossier or competitive intel.
• Crypto - words corrupt into scrambling hex and SIGNAL LOST. For the trader whose edge dies the second it is public.
• Cash - letters combust into floating dollar signs. For the money-leak audit.
• Focus - everything blurs the instant you move. For the productivity offer. The page will not let them skim, which is the product.
• Horror - the ink runs red and pools at the bottom. For fiction and the late-night read.
• Magic - words swell and puff out of existence. For the course creator selling a secret.
• Render - text falls into pixel noise and generates back when you stop. For the AI builder.
• Luxe - letters dissolve into gold dust, slow and expensive. For high-ticket, by-invitation.
• Sport - the page cracks like glass and blows apart. For the playbook, the game tape.
• Estate - the address fogs over like breath on glass. For the off-market listing.

You are still reading, so you want it live. Here is the exact build with the prompt included. The next parts show you every step and the one trap that stops most people.

One hidden number, call it heat, climbs while you move and falls while you sit still. Sixty times a second every word checks how hot things are and how close it is to your eyes, then decides how far into the burn it should be. Embers and smoke get painted on a clear sheet of canvas over the page. A few hundred lines of plain JavaScript keeping books. I wrote none of it. I described what I wanted in a paragraph, a tool built it, and the expensive skill stopped being can you code the fire and became can you say exactly what you want.

I built this in Claude Design. You describe the thing you want in plain English and it builds it as a live, interactive piece you can tune right there in the browser. No code editor, no canvas math, no animation library. Here is the prompt I started with. Steal it word for word and swap the brackets.

Build an interactive blog post called "[YOUR TITLE]." As the reader scrolls or moves the mouse, the body text [DESTRUCTION: catches fire, each word heats from ink to ember-orange, chars, and lifts off as rising embers and smoke on a full-screen canvas]. The words closest to where they are reading go first. When the reader holds still, it reverses and every word reforms into crisp, readable type. Tie the intensity to cursor speed, a slow drift is a light haze, a fast jerk is full destruction. Add a small corner meter showing the state. Match my brand, fonts and colors: [PASTE YOURS]. Keep it fully legible at rest, the effect only happens while the reader moves.

Swap the bracketed DESTRUCTION line for your lane. Redaction: "gets slammed under black bars with a faint CLASSIFIED stamp." Glitch: "corrupts into scrambling hex with RGB split and scanlines." Then direct it in plain English the way you would talk to a designer next to you. "Make it catch faster." "More smoke." "Add a genre switcher with all of these behind one row of buttons." Ten minutes of that gets you something that looks like a studio shipped it.

You finish it, hit export, drop the file on your site, and nothing moves. A dead, static page where the fire should be. Your site is fine. The file you exported was never a web page. The default export hides the JavaScript. When I opened the raw file Claude Design gave me, the top looked like this.

<script src="./support.js"></script>
...
<x-dc>
  <helmet>...</helmet>
  <div ref="{{ onChips }}">...</div>
  <div ref="{{ onHero }}">...</div>

Three things, and they are the whole problem. One, <script src="./support.js"> points at a runtime file you never receive. That file is the tool's engine. Two, <x-dc> and <helmet> are custom tags only the tool's runtime understands, and a normal browser ignores them. Three, ref="{{ onChips }}" is a template binding, not real HTML. The actual JavaScript is wired through those bindings into the runtime, not written into the page. So the markup is all there, the boxes show up, but the engine lives inside the tool. Drop that file where the runtime is not, and you get a beautiful corpse.

The fix is one sentence you paste back into Claude Design.

Give me this as a single standalone HTML file. No framework, no runtime dependencies. Just HTML, CSS, and vanilla JavaScript in one file I can drop into my site. Keep the real text in the actual page so crawlers and screen readers can read it, and respect prefers-reduced-motion.

Now it re-emits the same design with the runtime stripped and the real engine written into the page. That <script src> becomes a full inline <script> with the actual class in it. <x-dc> and <helmet> become a plain <div> and a normal <style>. ref="{{ onChips }}" becomes data-ref="onChips", a real attribute the inline engine reads on its own. One clean file. Double-click it and the fire runs with nothing else installed. That is the marry-up.

Now you hand that one clean file to Claude Code, which turns a file on your desktop into a thing live on your domain. If your site is a real app, like the Next.js site this post lives on, you do not just paste it in. You say "wire this into my site as a page," and it does the unglamorous work: lifts the engine into its own module, renders the markup as a component, makes sure your framework does not fight the animation, hooks the email box up to your actual list, adds the reduced-motion fallback, and gives it a real URL. That is exactly what made this page. The standalone was the proof it works. Claude Code made it a page instead of a file in my downloads. If your site is simpler, the job is smaller, and the standalone file does not need Claude Code at all to live somewhere. It runs anywhere. So here is every place you can put it.

Two ways, and which one depends on whether the platform lets you run a raw script. Method A, paste it in directly. Where a platform allows raw HTML with a script, you paste the markup, the style, and the one script into a code block and you are done. The text lives in your actual page, which matters for search. Method B, upload the file and iframe it. You upload the single file and embed it with one line.

<iframe src="your-file.html" sandbox="allow-scripts"
        style="width:100%;height:100vh;border:0"></iframe>

The effect runs in its own sealed window, no theme-CSS conflicts, no stripped scripts. The sandbox="allow-scripts" lets it run while stopping the framed page from touching the rest of your site. This is the one that always works.

The SEO tradeoff, know it before you pick. Google credits text inside an iframe to the iframe's own URL, not the page it sits on. So if this is a page you actually want to rank, use Method A, the native paste, which keeps the words where they count. If it is a campaign page or anything where ranking does not matter, iframe away. Do not iframe your homepage hero and expect it to help you rank.

One more, for hardened sites: Content Security Policy. If your site runs a strict CSP, it blocks inline scripts and inline styles, and the effect sits dead. Two fixes: move the script into its own file and allow it with a nonce or hash, or use Method B, the iframe, which runs in its own document. If you have no idea whether you have a CSP, you almost certainly do not, and you can ignore this line.

• Shopify. Custom HTML block for Method A. Or upload under Settings then Files and iframe it from a Custom Liquid section. No app needed.
• WordPress. The trap. The Custom HTML block strips script tags server-side unless you are an Administrator with unfiltered_html, and security plugins like Wordfence quietly remove them. Skip it: upload to your Media library and use the iframe.
• Webflow. The Code Embed element caps at 50,000 characters. The eleven-effect file is about 52KB, just over, so host it (GitHub plus the free jsDelivr CDN, or Webflow assets) and iframe it.
• Framer, Ghost, Squarespace, Wix. Embed element or HTML card for Method A, host plus iframe for Method B. When in doubt, iframe.
• Plain HTML site. It is the page. Upload it and you are done.
• React or Next.js. Render it client-side as a component, or iframe the file. No build step, no packages.

The truth most people selling locked-content effects will not tell you: the text is always sitting right there in the page. That is on purpose. Real text in the page keeps you readable to Google and screen readers, and it is not cloaking, the thing that gets you banned, because you serve the exact same HTML to bots and humans. But it also means anyone who opens DevTools, hits View Source, or turns off JavaScript can read every word without giving you an email.

For 95% of what you would use this for, that is fine. This is psychological gating, friction plus a fair trade, and it converts because most people will never bother to peek. A coupon, a lead magnet, an affiliate list, gate away. One word for the search-obsessed: this is the real content of your page revealed by a user action, which Google treats the way it treats tabs and accordions. Do not abuse it to hide stuffed keywords nobody is meant to read, that is the line.

But if you are hiding something that genuinely must stay hidden until payment, a paid post, a real secret, a code that costs you money every time it leaks, decoration will not cut it. Real security means the content is not in the page at all until your server sends it. The browser gets the locked version, the email submit hits a backend, the backend returns the goods. That is a real codebase job, and a perfect one for Claude Code. Here is the prompt.

I have a standalone HTML page with a text-destruction effect and an email-capture unlock. Right now the gated text lives in the page, so it is only psychological gating, anyone can View Source and read it. Make it real. The protected content must not be in the initial page. On email submit, POST to a serverless function (Vercel, Netlify, or Cloudflare), validate and rate-limit the request, store the email, and return the protected content only in the response. Render it client-side after a valid submit. Keep the destruction effect as the visual layer over a placeholder until then. Remember that storing emails means handling personal data, so add the basic privacy handling for my region. Stack: [YOURS].

Now the effect is the showmanship and the server is the lock. Best of both, hardened instead of held together with hope.

No email, no wall. Here are the two working files, entire. Copy one, swap the copy for yours, ship it. Each is a single self-contained HTML file: the text you want to destroy, the vanilla-JavaScript engine that burns and reforms it, and a canvas for the embers. Nothing to install. This is the shape of it.

<!DOCTYPE html>
<html lang="en"><head>
  <link href="fonts: Inter + IBM Plex Mono" rel="stylesheet">
  <style> /* brand colors + a prefers-reduced-motion block */ </style>
</head><body>
  <div id="bg-root">
    <div data-ref="onChips"> ...eleven effect buttons... </div>
    <main>
      <h1 data-burn>Burn After Reading</h1>      <!-- the text that burns -->
      <p data-burn>You already noticed...</p>
      <form data-onsubmit="onSubmit"> ...email... </form>
    </main>
    <canvas data-ref="onCanvas"></canvas>        <!-- embers + smoke -->
  </div>

  <script>
    class BurnGallery {
      buildWords() { /* split every word into its own span */ }
      paintWord(w) { /* fire | redact | glitch | blur | ... */ }
      loop()       { /* rAF: raise heat, paint words, draw canvas */ }
      unlock()     { /* sweep the text crisp again */ }
    }
    new BurnGallery(root, { mode: "auto" }).mount();
  </script>
</body></html>

What each part is doing.

• The markup. Your real text, tagged data-burn. It stays fully readable at rest, so crawlers and screen readers get the words, not ash.
• The engine. One vanilla-JS class. It splits every word into a span, paints the chosen effect frame by frame, and runs a canvas particle loop for the smoke and embers. No framework, no dependencies.
• The reveal. Submitting the email sweeps the text crisp again. That submit is the one line you rewire to POST to your own list, so the mechanic is the payoff, not a popup.
• Reduced motion. It reads prefers-reduced-motion and, for anyone who told their OS to stop animations, skips the whole effect and shows plain, readable text.
• The swap. Change three things and it is yours: the copy, the accent color, and the effect name. That is the whole customization.

Grab it. The full eleven-effect gallery, or the stripped lead-capture version the vault above is built on. Copy puts the entire file on your clipboard; Download saves it.

Deploy this on your worst page this week. Point the destruction at the one fear your reader already has. Then tell me whether your email rate moves. I run my own test in public and post the results in Friday's email. Subscribe and watch it work or watch it flop.

P.S. The cheapest version of this test is the one I am running. Put it on the page you care least about, point it at the one behavior your audience is trying to fix, watch what a single mechanic does to a single email rate, then move it to the page that actually matters. Make the medium the message and you are not decorating a page, you are proving a point.