Three-step trick: shrink a fanfic to 1 pixel, encode a command as garbled text, use a font to turn it readable

We pulled the source code of the demo page and found that the entire trick boils down to three actions, fewer than twenty lines of code in total.

Step 1: Shrink the fanfiction to 1 pixel, black text on black background

The fanfiction paragraphs are written inside tags like this. The page's background is pure black, so black text on a solid black background, with a height of just 1 pixel, is effectively invisible. For reference, the line you're reading is about 17 pixels high; 1 pixel is roughly one-seventeenth of that.

<p style="color: #000000;font-size: 1px;">This website was created as a tribute to Bioshock</p>

Step 2: The command meant for the human is written as a string of garbled text

In the center of the page is an ordinary <div> containing four lines of characters that look like a base64-encoded blob. An AI assistant seeing this would likely classify it as a "high-entropy string, unreadable without a key," and skip it as noise.

<div> vRmUwAgRmAiPjwUgARrhjAgRmbAshbVPjcUAcjwAsgrhAfcao
<br>RjJhAgRmAhnhJmshwAPsAsgrh
<br>fcaoADPAHBAFwhuFsJrF859E806E8E35F6266A2HB8
<br>PsAOPUUAcUUROAgRmAsRAahhAgRmbAhcashbAhWWAxbRVAMcrsmbh </div>

We also found something in the source code not mentioned in the research report or the news coverage. Directly above the garbled text block, there's another 1-pixel hidden text block containing just five words: LLM Generation Seed:. In other words, the AI reads "Generation seed:" followed by a string of random characters. It doesn't have to guess what this blob is — the attacker has already provided a label for it. This section wasn't present in the source code screenshot released by the researchers, indicating the page was modified after that screenshot was taken.

Step 3: Load a font where the letter drawings are swapped

The page header loads a font file and applies it to the entire page. With 48px font size, green text, and a black background, that's exactly what appears on the screen.

@font-face {
  font-family: 'fontie';
  src: url('RaptureFont.ttf') format('truetype');
}
body {
  font-family: 'fontie', sans-serif;
  font-size: 48px;
  background: #000;
  color: #0f0;
}

Individually, each of the three actions is perfectly legal. CSS lets you shrink text and match it to the background color. A <div> can contain any string. A webpage is allowed to load its own fonts. No JavaScript is used anywhere, and no browser exploits are involved. Disable JS entirely and the page still works its deception.

Why doesn't the AI notice anything? Because it only reads the code; the browser loads the font and re-renders

When an AI assistant fetches a webpage, it processes the page's code — referred to technically as the DOM (the in-memory text structure your browser builds after parsing the code). It looks at the tags, the structure, and the text within. It does not run the full browser rendering engine, download font files, or compute "what shape does this letter ultimately take when drawn." LayerX calls this class of assistant "non-agentic": they fetch the page and parse the code, but they don't execute a full render or analyze the custom font's glyph mapping.

The attack hinges on an assumption everyone takes for granted: the webpage code is the content, and fonts just make it look nice. Fonts don't change the meaning of the text. This assumption almost always holds, so nobody checks it. And because it's normally safe, the trick works so well.

There's another consequence. The assistant doesn't just fail to spot a problem; it actively tells you "this page looks safe."

When an attacker creates a malicious page and gets an AI assistant to label it safe, they're effectively appropriating that assistant's authority and using its credibility to vouch for their claim.

LayerX Research Report (our translation)

It's important to define the scope: this attack targets assistants that "read code only without rendering." If an assistant actually renders the page and looks at a screenshot, it would theoretically see those four lines of green text. LayerX didn't test such assistants; all 11 tested fall into the former category.

We dissected the fake font: what was swapped was the letter shapes, while the mapping table is clean

The following section is independent of the LayerX report and any news coverage. We downloaded the font file used by the demo page, read its internal tables, and re-rendered the garbled text with it ourselves.

A font file contains a 'cmap' table that maps "which glyph should character 'a' use?" The most obvious way to check if a font has been tampered with is to inspect this table. The cmap in this font is completely normal: character 'a' points to glyph 'a', character '0' points to glyph 'zero', all 5,918 mappings are clean. The GSUB and GPOS tables, responsible for glyph substitution and kerning/positioning, don't exist.

What was tampered with is the outline data in the glyph ('glyf') table — i.e., how each glyph is actually drawn. The glyph named 'a' contains the drawing of an 's'. Some immediately visible metrics:

Let's match the first 16 characters of the first line. The substitution pattern becomes obvious:

The entire substitution is strictly 1-to-1. The first line has 49 characters, and the recovered sentence also has 49 characters — no more, no less. All 169 characters across the four lines match up without conflicts. Here's the character mapping:

The trick has a flaw: copying the command on screen yields garbled text, forcing manual typing

If you select the command line on screen and press copy, the clipboard receives the characters from the webpage code — the garbled string — completely different from what your eyes see. The browser copies the characters themselves, not the drawn glyphs.

This means the demo page must compel the victim to type the command manually. The on-screen verb is literally "type," and the word "copy" appears nowhere. But this limitation only applies to this specific page. An attacker could add a script to modify the clipboard, making the copied text the decoded command. So the self-check below isn't foolproof.

Conversely, this provides a ready-made self-check. Similarly, using the browser's reading mode or disabling custom fonts breaks the disguise instantly — the disguise relies entirely on the page's own font. If you switch to a system font, the text reverts to garbled characters.

Did vendors fix it? Only Microsoft did. Google downgraded after initial high severity.

LayerX reported the discovery to various vendors in December 2025 (following responsible disclosure: private notification first, public disclosure after an agreed period). Six of the seven ultimately did not fix it, but for different reasons. Four initially said it was out of scope. Google accepted it and then reversed course. Perplexity said it was a general LLM limitation. Two of them essentially said "this is social engineering, not a compromise of our systems" — security professionals classify deceptive tactics like this as social engineering.

It's been over seven months since the tests in December 2025. We couldn't find any public information confirming whether the other vendors have quietly fixed the issue. What we can confirm is that the demo page and font file are still online. Fetching the page in plaintext still yields only the fanfiction and the garbled text.

LayerX's proposed fix: compare rendered output to the code, and treat fonts as an attack surface

The report suggests four detection measures for vendors, plus one requirement about how assistants should phrase their responses.

The first is the most practical: one path takes only the text from the code, the other performs a full render with fonts and extracts the visible text, then compares the two. This works without any prior knowledge of the attack method — whether it's font substitution, opacity tricks, or off-screen positioning — as long as what a person sees differs from what's in the code, it gets flagged.

The fifth item is about how assistants should communicate. If an assistant can't render a page, analyze custom fonts, or compare visual vs. code, it shouldn't say "this page is safe." For this case, fixing that final sentence is cheaper than any of the other four.

The web is more than HTML. Meaning can be moved into the rendering pipeline, and any system that only analyzes text is blind by default.

LayerX Report Conclusion (our translation)

The entire page is under twenty lines of code, has zero JavaScript, and uses no browser vulnerabilities. Disable all browser scripting and the page still works its magic.

We downloaded the font file from the demo page, read each table, and re-rendered the garbled text with it. One finding is surprising: the most obvious check yields nothing here.

This disguise has an unavoidable flaw: if you select the command on screen and press copy, the clipboard gets the raw characters from the code — the garbled string. The browser copies the characters themselves, not the drawn glyphs. So this particular demo page can only trick you into typing it manually. The verb on the page is literally "type." The word "copy" appears nowhere.

• Copy-paste to compare: a mismatch means something's wrong
• Use reading mode, or disable custom fonts: with system fonts, the text reverts to garbled
• Never manually type commands from unfamiliar pages
• Don't take AI's "safe" as the only verdict – it might not have seen the text on your screen (this is from LayerX & BleepingComputer; the other three are our derived self-checks)

LayerX reported the findings to various vendors in December 2025. Six ultimately didn't fix it, but for different reasons.

Dates and responses are from the disclosure timeline in the LayerX report. Assistant tests completed in December 2025, all self-tested by LayerX. Third-party reproduction is still pending. LayerX sells browser security products, so it has an incentive to emphasize severity. We have independently reproduced the attack. As of July 30, 2026, the demo page and font file remain online; fetching it as plaintext still yields only the fanfiction and garbled text. Whether the other vendors have quietly fixed it is unknown publicly.