ShieldFont Feeds AI Scrapers Nonsense While Readers See Normal Text

Two designers, Isaque Seneda and Gabriel Abrucio, have built ShieldFont: a typeface that shows human visitors a perfectly readable webpage while serving AI scraping bots a subtly altered, nonsensical version of the underlying HTML. The trick relies on font ligatures, a standard typographic feature normally used to tidy up letter pairs. ShieldFont repurposes that feature to swap whole words at render time, so any bot that grabs raw source code gets corrupted text that human readers never see. The designers published a white paper alongside the release.

What happened

Detail	Fact
Project name	ShieldFont
Designers	Isaque Seneda and Gabriel Abrucio
Mechanism	Font ligatures that replace entire words in rendered output
What scrapers receive	Altered, nonsensical plaintext from the HTML source
What readers see	Normal, readable text on screen
Published alongside	A white paper explaining the approach

ShieldFont is a typeface built specifically to corrupt the data AI companies collect when they scrape public websites for training material. Its designers describe it as a way to give web publishers “a practical opt-out from unauthorized AI training and to disrupt what is collected when that choice is ignored.”

How the ligature trick works

Ligatures are a long-standing feature in typography. Normally, a font uses them to merge certain letter pairs, such as “fi” or “fl”, into a single, cleaner glyph. ShieldFont extends that idea much further: it uses ligatures to detect entire words and replace them with different words when the font engine draws the page.

The key detail is timing. The substitution happens at render time, inside the font engine, not in the HTML source. A scraper that downloads the raw source code gets the swapped, corrupted text. A human reading the page in a browser sees the original, correct text because the font renders it correctly on screen.

Think of it like a one-way filter: the page looks fine to the human eye, but any pipeline that reads the underlying code, which is how most AI training data collection works, gets garbage in return.

Why does this matter for web publishers?

AI companies scraping the public web for training data has already triggered multiple lawsuits and pushed many publishers toward technical countermeasures such as robots.txt updates and paywalls. ShieldFont is a different kind of tool: it does not block scrapers outright, it poisons what they collect.

For a site owner who cannot afford to go dark or build a paywall, a font-level intervention is low-effort to deploy. If it works at scale, scrapers that ingest the poisoned text would train models on corrupted information, reducing the value of the stolen data.

There are real limits, though. Scrapers that render pages fully in a headless browser, simulating a real user, would see the same correct text a human does. Whether most large AI training pipelines bother with full rendering is an open question. Our bet is that many do not, which is exactly where ShieldFont would land its hit.

This kind of adversarial content strategy sits at the intersection of organic search and content protection, an area worth watching for any publisher thinking about how their content is being consumed beyond the browser.

Our take

ShieldFont is clever and technically sound at what it does. Ligatures are a legitimate part of the font rendering stack, not a hack, so this is not exploiting a bug. It is exploiting a gap between how humans consume pages and how most scrapers do.

That said, it is an arms-race move, not a permanent fix. The moment this approach gets widespread adoption, scraper operators will simply add headless rendering to their pipelines, and the advantage disappears. Right now, novelty is doing half the work.

For publishers who want a fast, no-paywall way to degrade the quality of data scraped from their site, it is worth a test. For anyone building serious content protection into a product, it should be one layer among several, not the whole strategy. If you are thinking about how your site handles AI data collection alongside your broader content and web development setup, that is a conversation worth having sooner rather than later.

We will also be watching whether search engine crawlers, which also render pages via font engines in some pipelines, are affected. The last thing a publisher wants is to accidentally scramble their own SEO text.

What to do about it

1. Read the ShieldFont white paper to understand exactly which scraper types it defeats and which it does not before deploying it on a production site.
2. Audit your current robots.txt and check whether major AI crawlers are honoring it, as a baseline before adding font-level countermeasures.
3. Test ShieldFont in a staging environment and verify that your page content renders correctly in multiple browsers and that no SEO-critical text is affected.
4. Monitor your search rankings after any deployment, since font rendering behavior varies across crawlers and you want early warning of any unintended content corruption.

For most publishers, ShieldFont is best treated as an interesting early experiment, worth testing on non-critical pages while proper data licensing and legal protections catch up.

Source: Ars Technica · AI