Burn After Reading

Here is the part nobody selling you a conversion hack will say out loud. I built it last week, I have run zero split tests, and I am putting it on a site that gets close to nobody, on purpose. If a page nobody visits can still pull an email out of a stranger, the mechanic works anywhere you bolt it. So this is not a how-I-made-40k post. It is a here-is-the-exact-thing post. Every step, every prompt, every place you can drop it, and the parts that will bite you if nobody warns you.

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.

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.

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.

A fire effect is fun. Flip one switch and it becomes a conversion mechanic. I will keep calling it a theory, because I have not proven it, but the logic is sound. Most CTAs get ignored. A popup interrupts and gets closed on reflex. Both of them ask. This does not ask. It takes something away and offers to give it back. Loss aversion is the strongest lever in buying psychology, and almost no marketing gets to use it, because you cannot take back something you never handed over. A page that destroys itself hands you the thing, takes it, then makes the email the one button that restores it. It forces a choice instead of requesting one. Here is one I built so you can feel it instead of imagine it.

Live demo, embedded with the exact sandboxed-iframe method described above. Codes are made up.

That is the same engine pointed at coupon codes instead of prose. Play with it, then steal the pattern. Four ways I would use it, and the honest theory for why each forces an action instead of asking for one.

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. Here is exactly what I did for a client and the dollar it produced, redacted until you subscribe. Show the work, gate the number. 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 members-only deal. A restaurant fogs its members deal until you join the SMS list. The deal is real, the lock is the join. The local owner's customer is standing in the store in the moment, so the reveal beats a generic "join our list."

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 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.

Both files are yours to take apart. If you ship one, tell me whether your numbers beat my theory - right now the theory is all I have got.

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.