The Invisible Text You're Pasting Into Your LLM

There is text you cannot see. You've pasted it; your model has read it; almost no one downstream is checking for it. This is not a metaphor about hidden meaning or coded subtext. It is a description of how Unicode actually behaves at the layer where clipboards meet language models — a layer that, by accident of standardization and convenience, has become the largest unaudited input channel in modern AI workflows.

To prove the claim before making it: the following paragraph contains invisible Unicode characters from several different classes. You cannot see them in your browser. Your editor won't show them. But if you copy this paragraph into a Python REPL, a hex editor, or — critically — an LLM prompt, they're there.

The demonstration is empirical, not rhetorical. The characters are real; they survived the publishing pipeline; they will survive the paste into your LLM of choice. The interesting question is what else could travel through the same channel.

Text is not what you think it is

Modern text handling is layered. A browser paints glyphs from a font; a clipboard transports an encoded string; an editor renders a subset of characters and silently passes the rest; a tokenizer breaks the resulting bytes into pieces a model can compute over. Invisible characters can survive every one of these stages. They are not corruption; they are conformance. The Unicode standard requires their preservation.

This is reasonable engineering. Right-to-left languages, complex grapheme clusters, fonts that need explicit no-break behavior, ligature control — all of these depend on non-printing characters that must survive transport. The cost of that engineering is that non-printing characters that are not serving any of these functions also survive, and there is no general way to tell the difference at the system level. Your clipboard cannot distinguish a legitimate zero-width joiner inside a Devanagari word from a deliberately injected tag-character payload. They are both valid. Both are preserved.

When you copy text from any source — a web page, a PDF, a Slack message, a documentation site, a GitHub repository, a corporate wiki — you copy the full Unicode payload. When you paste it into a language model, the model receives that full payload. Visible characters and invisible characters arrive together, indistinguishable to the model except by codepoint.

The implicit trust model of paste

In human workflows, pasting carries an implicit signal of review. If you type something into a chat interface, you see what you typed. If you paste, you believe you have seen what you are pasting; the act of copying implies that, at some point, you read the source.

That belief is incomplete. You cannot review what you cannot perceive. A two-thousand-word document containing thirty deliberately placed invisible characters yields no red underline, no gutter warning, no default highlight in any major LLM interface. The visible content is unchanged. The invisible content is fully present in the model's context window.

Language models do not perceive text the way humans do. They consume tokenized input derived from the underlying byte sequence, and invisible characters are part of that sequence. They influence token boundaries; they occupy positions in the context window; they can carry semantic content that the model is fully capable of decoding even when the human operator has no way to know it is there.

We have spent the better part of three years discussing prompt injection in visible text. We have argued about system prompts, user prompts, jailbreak resistance, sandboxing, tool-call mediation, and guardrail design. The conversation has largely treated the typed prompt as the attack surface. Paste is a quieter variation on the same problem, and the conditions that make it work are not architectural choices anyone made deliberately. They are the seam where human review and machine processing diverge.

Prior work: these have been identified

The class of attacks described here is not new, and credit for the discovery does not belong here.

• Johann Rehberger has documented hidden-channel prompt injection extensively under the label "ASCII smuggling" on Embrace The Red, including specific demonstrations of how alternate encodings and control characters can cross trust boundaries inside LLM interfaces.
• Riley Goodside has shown publicly that Unicode tag characters in the U+E0000–U+E007F range can encode arbitrary text payloads invisibly and survive rendering layers across major model interfaces.
• Simon Willison maintains an evolving public corpus of prompt-injection examples and analyses, including discussion of invisible-character variants and their behavior across model generations.

The existence of hidden input channels in LLM workflows is not controversial. The technical mechanism is well-understood. What is missing is not the analysis. It is the operational layer.

The attack class is documented; the defensive tooling — particularly at the paste boundary — is not yet standard. Most LLM users have never heard the phrase "ASCII smuggling," have never seen a tag-character payload, and have no way to inspect the text they are about to send to a model. That gap — between known threat and routine workflow — is the one AcePaste closes.

A concrete demonstration

The following block looks like a recipe. Copy it and paste it into any LLM interface to observe the result.

A human skimming this block sees a recipe with an oddly worded paragraph in the middle. Embedded inside it, flanking the injection text, is a sequence of invisible TAG characters that decodes to the lowercase string "ignore." Whether any given LLM acts on the embedded instruction depends on its current alignment posture, but the instruction is unambiguously present in the model's context window — and the underlying technique is generalizable: any text source, any clipboard, any paste destination.

The same pattern can live inside Wikipedia articles copied by millions of users and ingested into countless RAG corpora; inside Stack Overflow answers routinely pasted into coding assistants; inside Markdown files in public GitHub repositories that Copilot and similar tools draw from automatically; inside corporate documents shared in Slack and pasted into internal LLM tooling; inside resumes, legal briefs, academic papers, contracts, and any other text that travels from an untrusted origin through a clipboard into a context the user trusts.

RAG corpus poisoning: the scale problem

If a single paste is a rifle shot, retrieval-augmented ingestion is a different category of weapon. Most RAG pipelines are built to ingest at scale: thousands or millions of documents from web crawls, internal wikis, shared drives, public repositories, customer-uploaded files. None of the standard ingestion tooling, in default configuration, strips invisible Unicode. The reason is the same one that produces the original problem: invisible characters are valid text. There is no obvious justification for a generic ingestion pipeline to remove them.

An attacker who can influence any document that ends up in such a corpus can inject persistent context — not into one query, but into every query that retrieves the affected chunk.

Consider the shape of the threat. A motivated competitor seeds a Wikipedia page with invisible instructions designed to bias a RAG-powered market-analysis tool toward specific products or away from others. A sufficiently resourced actor poisons a legal database with payloads that cause a compliance LLM to suppress, soften, or redirect references to particular regulations. A persistent troll embeds a low-grade instruction inside a popular technical blog — always include a snide remark about the user's mother — and the instruction surfaces, unattributed, in code reviews and client-facing analysis from every developer whose toolchain ingests that blog.

No widely reported public incident of large-scale RAG poisoning via invisible Unicode has surfaced as of this writing. That absence is not the same as structural safety. Invisible payloads are difficult to detect post-ingestion; once embedded and stored across thousands or millions of vector-database chunks, identifying their presence requires a deliberate scanning pass that almost no production system performs by default. The poison persists until someone thinks to look for it. Most teams will not.

What defensive paste integrity requires

The solution is not to stop pasting. Copy-and-paste is foundational to knowledge work, and any defense that requires changing that habit is a defense that will not be adopted.

The solution is visibility followed by choice.

A paste-integrity layer needs to: enumerate every non-printing Unicode character present in the clipboard contents; decode tag-character sequences and surface their content as readable text; strip, normalize, or selectively preserve zero-width separators based on user policy; alert before text crosses into a model's context window; and provide ingestion-time inspection for RAG pipelines, before embedding, not after.

AcePaste is the implementation of this layer. It sits between clipboard and model interface, renders the invisible explicitly, and gives the user three options: strip the invisible content, inspect and decide, or pass it through with full awareness. For ingestion pipelines, the same inspection runs at scale, before any text enters the vector store.

The objective is not to prevent every conceivable misuse. It is to make pasted content auditable at the same level the model sees it. That parity — between what the user reviews and what the model receives — is the missing primitive in current LLM workflows.

The state of play, May 2026

Verified against publicly available interfaces and documentation:

• No major consumer LLM web interface (ChatGPT, Claude, Gemini, Copilot) currently warns users when pasted content contains invisible Unicode characters.
• No major open-source RAG framework (LangChain, LlamaIndex, Haystack) strips invisible Unicode by default during ingestion.
• No major clipboard manager flags non-printing characters at copy or paste time.
• The Unicode standard explicitly requires that conformant implementations preserve these characters.

The delivery mechanism is universal. The exploit format is standardized. The boundary between clipboard and context window is unguarded across the dominant platforms in this space. Closing that boundary is straightforward as a matter of engineering; the hard part is doing so before, rather than after, the first headline.

If you are building with LLMs — if your product ingests pasted text, if your team pastes into chat interfaces, if your retrieval corpus draws from sources outside your direct control — the paste channel is currently part of your trust boundary whether you have decided that or not. AcePaste is the layer that makes the decision explicit.