What Is ShieldFont? The Open-Source Anti-AI Scraping Font

Introduction

In the movie The Matrix, what people believe they see in the real world is not reality. They’re mentally trapped in bubbles connected to machines that feed them a fake version of the world.

Behind everyone’s mind sits a stream of code that machines can read very differently from the humans living inside the simulation.

The same idea is now being applied to the web. What if an article could look perfectly normal to a reader while an automated scraper collecting its underlying text walked away with something else entirely?

Enter ShieldFont, an experimental approach to protecting online writing from AI web scrapers by creating a gap between what humans see and what machines extract.

An AI scraper is an automated tool that scans websites and collects text, images, or other data, often so it can be used by AI systems for training, research, analysis, or generating answers. In simple terms, it is a bot that reads and copies website content at scale.

So, what is ShieldFont and how does this anti-AI scraping web font work?
 

What Is ShieldFont?

ShieldFont is a system designed to make online writing more difficult and expensive to collect through automated mass scraping.

The project began in October 2025 with Isaque Seneda and Gabriel Abrucio of creative studio S&A, working with Danish type foundry Playtype, which provided its Optik typeface for the project. As of August 2026, the GitHub repository lists ShieldFont v0.3.2 with its v18 Alpha mapping as the default.

The underlying idea sounds almost contradictory:

Humans and scrapers can request the same webpage but interpret different words.

ShieldFont achieves this by storing substituted words in the text sent to a scraper and using OpenType font rules to visually convert them back into the author's intended words when the page is rendered in a browser.

This makes ShieldFont different from conventional anti-scraping technologies.

A web application firewall might prevent a crawler from accessing a page. A robots.txt file can tell crawlers that the publisher does not want certain URLs crawled. ShieldFont instead assumes that scraping may still happen and attempts to reduce the usefulness of what gets collected.

The idea behind ShieldFont is fairly straightforward, but its open-source status is a little more nuanced. While the project is widely referred to as an open-source font, that description does not tell the whole story.
 

Is ShieldFont Really An Open-Source Font?

Yes, but there is one crucial technical distinction.

Describing ShieldFont as an open-source font is convenient, but not entirely precise.

The ShieldFont code is released under the AGPL-3.0 license. Fonts generated from compatible Open Font License typefaces can also use OFL 1.1. However, the default ShieldFont implementation is based on Playtype's Optik, which is being used with permission and is not itself an open-source font.

It is therefore more accurate to describe ShieldFont as an open-source anti-scraping protocol and toolkit that can work with fonts, including custom fonts.

That distinction matters when discussing licensing, commercial deployment, and what developers can freely redistribute. However, ShieldFont’s real intrigue lies in how it alters machine-readable text to confuse AI scraping and training pipelines.
 

How Does ShieldFont Disrupt AI Scrapers?

To understand ShieldFont AI scraping protection, imagine that you publish the following sentence:

The knight rode his horse into battle.

The browser might show exactly that to a human. However, the underlying text collected by a basic AI scraper could contain something closer to:

The knight rode his engine into battle.

The sentence is still grammatically recognizable, but an important piece of its meaning has been changed. That difference is intentional.


ShieldFont works in three main steps:
 

Step 1: ShieldFont Chooses Meaningful Words

ShieldFont does not randomly scramble every word.

Its current system concentrates on content-heavy parts of language such as nouns, verbs, adjectives, and adverbs while leaving many structural words untouched. The project's white paper says the current mapping changes roughly 24.4% of all running words and about 45.8% of content words.

The developers also maintain rules designed to avoid simple synonym or antonym replacements, because those substitutions would either preserve too much meaning or become easier to reverse predictably.
 

Step 2: HTML Contains The Decoy

The protected text must be encoded before it reaches the visitor's browser in plaintext.

For the recommended React implementation, ShieldFont performs the encoding during server rendering or the build process. The project's documentation specifically warns developers not to put the unprotected original text into client-side code, where a scraper could simply retrieve it.
 

Step 3: Font Reconstructs What Humans See

A browser downloads the ShieldFont font file and applies its OpenType substitution rules when rendering the webpage.

Those rules transform the altered underlying word into the glyphs (visual shapes of characters in a font) representing the word the writer actually wants readers to see.

The concept builds on capabilities fonts have used for years, particularly substitution features associated with ligatures (special combined glyphs). ShieldFont extends the basic idea from character combinations to whole-word mappings.

Once ShieldFont has altered what automated systems collect, the next question is what happens to that distorted text after it enters an AI training pipeline. Does it merely make scraped data less reliable, or can it actually poison the dataset itself?
 

Does ShieldFont Really Poison AI Training Data?

"Poisoning" is one of the terms most commonly associated with ShieldFont, but it needs some context.

The project's benchmark tested four sets of text. According to ShieldFont, 55.8% of tested news passages, 51.9% of general web passages, 34.5% of fiction passages, and 31.1% of older fiction passages stopped expressing the same claim after ShieldFont's substitutions. A synonym-swapping control produced a much smaller 2.1% result.

ShieldFont also attempts to exploit the data-cleaning stage of AI training.

If altered text looks sufficiently poor, a quality filter may reject it, and the original work never reaches the training dataset through that particular pipeline. If altered text survives filtering, the theory is that the dataset receives plausible but semantically altered content instead.

The developers are careful about the limits of this claim. ShieldFont's GitHub documentation explicitly says the project does not claim that its encoded text has been proven to damage a model trained on it.

At this stage, ShieldFont has stronger evidence for changing scraped text and reducing its usefulness than for demonstrating measurable degradation of large commercial AI models.

ShieldFont may not completely poison AI training data, but it can make scraped content less reliable, giving publishers a rare way to push back against AI scrapers.
 

Why Is ShieldFont Being Called The Newest Weapon Against AI Scrapers?

ShieldFont arrives as publishers are experimenting with several ways to control AI crawling. One of the oldest options is robots.txt.

Google describes robots.txt primarily as a mechanism for controlling crawler access and warns that it is not a security mechanism for keeping sensitive content private.

AI crawler operators and GenAI companies can choose to respect these instructions. OpenAI, for example, documents separate controls for GPTBot and OAI-SearchBot so publishers can communicate crawling preferences.

The limitation is enforcement.

A robots.txt rule communicates what a website owner permits. It does not physically prevent every possible scraper from requesting the URL. Cloudflare has similarly described robots directives as expressions of preference rather than hard enforcement and offers network-level bot-blocking controls as another layer.

ShieldFont approaches the problem from another direction: Instead of relying entirely on identifying and blocking the scraper, alter the value of the data the scraper receives.

That is why the technology has garnered attention as the newest weapon against AI scrapers rather than simply another crawler-blocking feature.

Although ShieldFont seems promising enough, there are concerns whether AI scrapers can ever circumvent its trap.
 

Can AI Scrapers Bypass ShieldFont?

Yes. This is one of its most important limitations. Even ShieldFont’s developers openly acknowledge multiple bypass techniques.
 

1. Reverse The Font Mapping

The browser needs the font to display the correct words.

That means a sufficiently motivated scraper can download the font and inspect its substitution rules. The ShieldFont team says it successfully recovered all 11,962 pairs from one of its own shipped fonts during testing.

Private mappings make this less convenient because a universal decoder will not necessarily work across every ShieldFont deployment, but they do not turn the mechanism into cryptographic protection.
 

2. Render The Page In A Browser

ShieldFont primarily targets scraping systems that consume underlying text without fully reproducing what a human sees.

A headless browser capable of properly rendering the font can potentially recover the visible version. ShieldFont lists rendered headless browsers among the methods outside its intended defense boundary.
 

3. Screenshot And Use OCR

A screenshot contains the letters displayed to the human reader.

An OCR system can therefore read those letters instead of the poisoned HTML. Vision-capable AI can potentially do the same.

The argument behind ShieldFont is economic rather than absolute: rendering, capturing, and visually interpreting enormous numbers of webpages requires more processing than simply downloading HTML.

Publishers might receive optimized protection from scrapers but at the cost of compromising SEO visibility.
 

ShieldFont's Major Trade-Off: SEO

There is an obvious tension between writing an article for search engines and using ShieldFont to protect that same article from automated text extraction.

Googlebot also needs machine-readable page content.

ShieldFont's documentation warns that search engines can index the substituted words rather than the human-visible version. Therefore, fully shielding content you want to rank organically can interfere with SEO.

For publishers dependent on Google traffic, that is a substantial cost.

The developers recommend selective deployment. A publisher might keep titles, navigation, summaries, and important acquisition pages unprotected while shielding archives, premium writing, essays, or sections that do not depend heavily on organic discovery.

So, ironically, the article you are reading about ShieldFont would probably not be a good candidate to shield completely if ranking for "what is ShieldFont" was its primary objective.
 

Accessibility Is Another Serious Limitation

The accessibility issue deserves equal attention.

Screen readers often work from machine-readable page content rather than interpreting custom fonts visually. Without intervention, that means a screen reader could encounter ShieldFont's decoy words rather than what sighted readers see.

ShieldFont's React implementation attempts to handle this by hiding the scrambled version from accessibility tools and providing an alternative mechanism that releases the correct text after the user's browser completes additional computation.

However, the project's own GitHub documentation says shielded blocks still fail WCAG 2.2 Success Criterion 1.3.1 and advises sites with applicable accessibility obligations not to shield covered content.

Early Reddit discussions around ShieldFont also focused heavily on accessibility, copy-and-paste limitations and the ease with which technically sophisticated scrapers might work around the system. Those comments are anecdotal rather than formal testing, but they closely mirror limitations acknowledged by ShieldFont itself.
 

Other Limitations Publishers Need To Consider

SEO and accessibility are not the only compromises.
 

• Copy And Paste

  Copying protected text can return the substituted underlying words rather than the words displayed on screen. That may frustrate readers trying to quote or reference an article.

• Translation

  Machine translation tools that extract underlying text may translate the decoy instead of the intended copy.

• Find-In-Page And Reader Modes

  Some browser features that depend on the underlying text can become unreliable inside protected sections.

• Content Feeds Can Leak The Original

  RSS feeds, JSON-LD, Open Graph metadata, and CMS APIs may expose plaintext independently of the rendered page. ShieldFont's documentation therefore advises publishers to inspect these additional content paths instead of assuming that applying a custom font automatically protects the entire publishing stack.

• English Only

  The current mappings protect English. Supporting other languages requires language-specific mappings rather than simple automated translation.

These limitations mean ShieldFont isn’t for every page. So, who could benefit most from using it?
 

Who Should Consider Using ShieldFont?

ShieldFont makes the most sense where protecting authorship is more valuable than maximizing automated discoverability. Potential candidates include:
 

• Independent essays

• Premium editorial archives

• Fiction and literary writing

• Research drafts

• Manifestos

• Original commentary

• Member-only content

• Certain PDF or document workflows

• Content whose primary audience arrives directly rather than through search

The project itself advises against using ShieldFont on government or service-critical information, content that users need to reliably quote or search, and content subject to accessibility requirements that the current implementation cannot satisfy.

For SEO-dependent publishers, selective implementation is much more realistic than shielding an entire website.
   

Should You Use ShieldFont To Block AI Web Scrapers?

If your goal is to completely block AI web scrapers, ShieldFont alone is not the answer.
It does not authenticate visitors, block network requests, or guarantee that AI systems cannot recover the visible text.

Its purpose is different.

ShieldFont tries to change the economics of indiscriminate scraping. If a crawler can normally collect millions of pages by cheaply downloading HTML, requiring it to identify custom mappings, fully render pages or run OCR creates extra computation and complexity.

The goal is to increase the cost per scraped page rather than claim perfect protection against a determined target.

A more defensible strategy would combine several layers:
 

• Publish clear crawler permissions through robots.txt.

• Use network-level or WAF bot controls where appropriate.

• Protect genuinely restricted content through authentication.

• Consider licensing mechanisms for AI access.

• Use ShieldFont selectively where adding friction to unauthorized bulk extraction is worth the usability of trade-offs.

ShieldFont may not stop AI scraping entirely, but it hints at where anti-scraping defenses could be headed next.
 

Final Thoughts

So, what is ShieldFont? ShieldFont is an experimental anti-AI scraping system that exploits the difference between the text stored in a webpage and the typography rendered for a human reader.

It can make low-cost AI web scrapers collect altered words while people continue seeing the intended content. Tests published by the project suggest those substitutions can substantially change the factual meaning of scraped passages.

Yet the technology should not be mistaken for foolproof ShieldFont AI scraping protection. AI scrapers can potentially defeat it with custom decoders, fully rendered browsers, OCR, and computer vision. Search visibility, accessibility, translation, and basic features such as copy and paste can also suffer.

That is why ShieldFont's most interesting contribution may not be the font itself. It is the idea that protecting online creativity does not always have to mean closing the door. Sometimes, it can mean making unauthorized collection sufficiently inconvenient, uncertain, and expensive that asking permission becomes the easier option.