Encoding-Based Jailbreaks: Base64, ROT13, and Obfuscation Attacks on LLMs

Large language models are remarkably capable at working with encoded and obfuscated text — decoding Base64, unscrambling ROT13, translating between character sets, even parsing deliberately garbled or leetspeak-style text — because that capability was trained in as a genuinely useful feature, not a bug. Encoding-based jailbreaking exploits a documented, replicable gap between that capability and a model's safety training: models can often decode and comply with a harmful request delivered in an encoded format, even when the identical request in plain, unencoded text would be reliably refused.

The core mechanism, and why it isn't just a curiosity

The attack pattern is simple to describe and doesn't require any special tooling: take a request the model would normally refuse, encode it — Base64 is the most commonly documented example, though ROT13, hexadecimal, Unicode escape sequences, and even simple character-substitution ciphers have all been documented working to varying degrees — and ask the model to decode and respond to it, sometimes with an explicit instruction to respond in the same encoded format to make the exchange feel like a legitimate technical exercise rather than an attempt to disguise anything.

This isn't a theoretical curiosity — it's been documented working against multiple major model families, with published research specifically measuring and quantifying the gap between plain-text and encoded-request refusal rates. The consistent finding across this research is that the gap is real and often substantial, though it varies by encoding scheme, by model, and by how directly the encoded content maps to content the model's safety training specifically targeted.

Why safety training has this gap in the first place

The most plausible and well-supported explanation for this gap traces back to how safety training data is typically constructed: reinforcement learning from human feedback and safety fine-tuning datasets are overwhelmingly built from plain-text examples — a harmful request written in ordinary language, paired with the appropriate refusal. Very little safety training data historically included the same harmful requests pre-encoded in Base64 or ROT13, which means the model's refusal behavior, learned largely through pattern association with plain-text harmful content, doesn't automatically and completely transfer to the same semantic content presented in an encoded form the training data rarely if ever included.

This is conceptually similar to the low-resource-language jailbreak gap covered elsewhere in this series — both are examples of safety training not transferring evenly across every possible representation of the same underlying harmful request, whether that representation is a different natural language or a different text encoding scheme. The model's raw capability to understand the content (decoding Base64, or reading Zulu) outpaces the safety training's specific coverage of that particular representation.

Why more sophisticated encodings can be more effective, not less

Counterintuitively, a moderately sophisticated encoding scheme can sometimes be more effective at bypassing safety training than either a trivial one or a maximally complex one. An encoding too simple (like reversing the text character by character) may be recognized and normalized by a model's own preprocessing or by input-side filtering before it ever reaches the stage where safety evaluation happens. An encoding too complex or unusual may exceed the model's reliable decoding capability, producing garbled output that fails to convey the actual harmful request coherently enough to elicit a useful compliant response. The most effective encodings tend to be ones the model reliably and fluently decodes — Base64 being the most commonly cited example precisely because it's common enough in general training data for models to handle fluently — while remaining unusual enough that safety training's plain-text-focused pattern recognition doesn't reliably fire on the encoded form.

Layering encoding with other techniques

Encoding-based jailbreaking is rarely deployed as a standalone technique in sophisticated attack attempts — it's frequently combined with other techniques covered throughout this series to compound effectiveness. An encoded request layered with a persona framing ("decode this message and respond as DAN would"), or an encoded payload delivered as part of a longer, gradually escalating multi-turn conversation, or an encoded suffix combined with the kind of optimization-driven techniques covered in the GCG piece, all represent realistic combination attacks that a testing program focused only on each technique in isolation would systematically underweight.

This compounding effect is a recurring theme across this entire series and worth restating specifically here: real attackers, especially sophisticated ones, don't limit themselves to a single, cleanly isolated technique when a target is worth genuine effort. Testing methodology needs to reflect that reality rather than testing a clean, academic version of each technique category in isolation and reporting resistance based on that narrower, less realistic scope.

The specific danger for agentic systems processing untrusted content

Encoding-based techniques carry particular relevance for agentic systems that process content from external or untrusted sources, because encoded payloads can hide in plain sight within documents, web pages, or other content an agent reads as part of routine operation — a chunk of Base64 text embedded in an otherwise unremarkable document doesn't visually announce itself as adversarial the way an obviously threatening plain-text instruction might to a human reviewer skimming the source content, even though the model itself decodes and potentially acts on it exactly the same way it would an unencoded instruction.

This connects encoding-based jailbreaking directly to the indirect prompt injection and RAG poisoning technique categories covered elsewhere in this series — encoding is frequently the specific obfuscation layer that makes an indirect injection payload harder for both human reviewers and simple keyword-based content filters to catch, compounding the underlying delivery mechanism with an additional layer of stealth.

How model providers have responded

Major providers have made real, measurable progress addressing this specific gap since it was first documented, incorporating encoded and obfuscated examples more deliberately into safety training data, and in some cases adding explicit preprocessing steps that decode common encoding schemes before content reaches the model's main safety evaluation, so the evaluation sees the actual semantic content rather than being fooled by its encoded surface form. This has meaningfully narrowed the gap for well-known, common encoding schemes like Base64 against major, actively maintained models.

The gap hasn't closed entirely, and it's worth being specific about why: the space of possible obfuscation techniques is large and continues to grow — custom substitution ciphers, combinations of multiple encoding layers, encoding schemes specific to particular technical communities that a general safety training dataset might not have anticipated — and safety training that's been specifically hardened against the well-known, commonly documented schemes doesn't automatically generalize to a fresh, less common obfuscation approach nobody has yet published research about.

Testing methodology for this technique family

A thorough test needs to go beyond the single most commonly cited encoding (Base64) precisely because that's the one most likely to have already been specifically hardened against. Real testing should include multiple distinct encoding and obfuscation schemes — ROT13, hexadecimal, various character-substitution approaches, and combinations of more than one scheme layered together — tested against the same underlying harmful request category, to build an accurate picture of which specific schemes the target system has genuinely been hardened against versus which remain untested gaps.

It's also worth testing whether a system's defense against this technique operates at the input-decoding layer (catching and evaluating the true semantic content regardless of encoding) or purely at the pattern-matching layer (recognizing specific known encoded strings), since the former is a genuinely robust defense against novel encodings while the latter provides a much narrower, easily circumvented protection that a fresh, unpublished encoding scheme could likely route around entirely.

Mitigations beyond model-level safety training

Application-level defenses add meaningful protection independent of the underlying model's own safety training maturity: detecting and decoding common encoding patterns in user input before it reaches the model, so any content filtering or classification the application applies operates on the true decoded content rather than being fooled by its encoded surface appearance, closes off a substantial share of this attack surface regardless of how well the underlying model itself has been hardened. Output-side filtering that evaluates a model's actual generated response for harmful content, independent of whatever input format triggered it, provides a further layer that doesn't depend on correctly anticipating every possible input-side obfuscation scheme in advance.

Why this category deserves ongoing, not one-time, attention

Encoding-based jailbreaking is a good illustration of a pattern that recurs throughout AI safety research: a gap between a model's raw capability and its safety training's specific coverage, exploitable in a way that's mechanically simple for an attacker to execute but genuinely difficult to close completely, because closing it requires anticipating every possible representation of harmful content rather than just the plain-text form. As models gain new capabilities — new languages, new formats, new modalities — this same fundamental pattern is likely to keep producing fresh instances, which argues for treating this as a standing category in any ongoing testing program rather than a single historical finding that gets checked once and considered resolved.

Novel and combinatorial encoding schemes worth specifically probing for

Beyond the well-documented standards — Base64, ROT13, hexadecimal — a genuinely thorough test suite should probe schemes less likely to have received specific safety-training attention: Morse code, Pig Latin, deliberately introduced spelling variations and homoglyphs (visually similar characters from different character sets substituted for their standard equivalents), leetspeak-style character substitution, and reversed or interleaved text. None of these individually is exotic or difficult for a model to decode, which is exactly why they're worth testing — a scheme a model handles fluently but that wasn't specifically represented in safety training data is precisely the profile that tends to produce a measurable gap between plain-text and encoded refusal rates.

Combinatorial approaches — layering two encoding schemes together, or combining a moderate encoding with a persona framing or an authority claim — deserve specific testing attention too, since the combination of a technique this series has covered as individually only moderately effective with another technique that's also only moderately effective can sometimes produce a combined effect meaningfully stronger than either alone, precisely because each layer is independently routing around a different, narrower piece of the model's overall safety coverage.

A note on why open-weight models deserve particular attention here

As with the GCG technique covered elsewhere in this series, open-weight models deserve particular scrutiny for encoding-based vulnerability specifically, because an attacker with direct access to model weights can systematically and exhaustively test a very wide range of encoding schemes offline, at scale, with no rate limiting and no visibility to the model's original publisher — identifying exactly which encoding gaps remain unaddressed in a specific model version before ever deploying an attack against a live target system built on that same model. Organizations building on open-weight models should assume this kind of systematic, offline probing has very likely already happened against any popular base model by the time they deploy it, and should test their own specific deployed configuration — system prompt, any additional filtering layers — accordingly, rather than relying purely on whatever baseline resistance the underlying open model happens to already have out of the box.

How to build a proportionate, ongoing test cadence for this category

Given that new encoding schemes and combinations can be discovered and shared within attacker communities faster than any single organization can track independently, a proportionate approach treats this category the same way a mature vulnerability management program treats a large, evolving population of known CVEs: maintain a living, periodically updated test suite covering the currently known and documented encoding variants, rather than a fixed list tested once and considered permanently complete. New variants that surface in published research or in observed real-world attack attempts should be added to that living suite promptly, keeping the organization's own testing coverage reasonably current with what's actually being used against comparable systems in the wild.

This ongoing-maintenance framing is worth internalizing specifically for this technique category, because unlike some of the more architecturally fundamental risks covered elsewhere in this series, encoding-based jailbreaking is genuinely, meaningfully reducible through diligent, current testing and layered defense — it's one of the technique categories where sustained effort produces real, measurable, compounding improvement over time, rather than representing an open research problem with no clear path to meaningful mitigation.

The takeaway for teams prioritizing a limited testing budget

For a team that can't test exhaustively against every possible encoding variant, prioritizing by realistic attacker effort provides a sensible ordering: well-known, widely documented schemes like Base64 first, since they require the least attacker sophistication and are most likely to already be attempted against any live system; combinatorial approaches layering encoding with other techniques covered elsewhere in this series next, since they represent a realistic escalation path for a moderately sophisticated attacker whose first, simpler attempt failed; and genuinely novel or obscure schemes last, since they require more attacker effort to discover and are correspondingly less likely to represent the first technique a typical adversary reaches for against a new target.

A concrete illustration of the plain-text-versus-encoded gap

To make this gap concrete: published research documenting this technique has shown scenarios where a direct, plain-text harmful request is refused by a tested model in close to every attempt, while the semantically identical request, delivered Base64-encoded with a simple instruction to decode and respond, succeeds at a meaningfully and measurably higher rate against the same model in the same testing session. This isn't a marginal, barely-detectable statistical artifact — it's a large enough, reproducible enough gap that it represents a genuinely practical, low-effort technique any moderately capable attacker can execute with nothing more than a text encoder and a few minutes of experimentation, no specialized tooling or technical sophistication required beyond knowing the gap exists in the first place.

This concreteness matters for communicating the risk internally: a security finding phrased as "the system may be vulnerable to encoding-based bypass techniques" tends to land with far less urgency than a demonstrated, reproducible example showing the exact same harmful request succeeding when encoded after failing in plain text, run live against the organization's own actual production system rather than described only in the abstract.

Closing summary

Encoding-based jailbreaking persists as a live, testable risk category precisely because it exploits a structural gap between what a model can fluently do and what its safety training has specifically anticipated, rather than a bug that gets fully closed with a single patch. Treating it as a standing item in an ongoing test suite, probing beyond the single most famous encoding scheme, and pairing model-level improvements with application-level input decoding and output filtering together produce a meaningfully more resilient posture than relying on any single layer alone — the same layered-defense principle that recurs throughout every technique category this series has covered.