Why Epstein Files Have Random Equal Signs Everywhere

When the Epstein files dropped, people started seeing patterns everywhere. Some thought the random equal signs scattered throughout the emails were some kind of code. Decode them, the theory went, and you'd unlock hidden messages about where Jeffrey Epstein was really hiding.

The actual explanation is less exciting and more embarrassing: it's a collision between 1996 email standards and whatever document processing pipeline the government used to redact and release these files. No conspiracy. Just legacy code doing what legacy code does—failing in exactly the way it was designed not to fail.

The Original Sin: RFC 2045

To understand why "confiden=tial" and "prop=erty" litter these documents, you need to go back to November 1996 and RFC 2045, which established MIME (Multipurpose Internet Mail Extensions). Buried in that specification is something called "quoted-printable encoding," designed to make email readable on those 80-character terminals everyone was using in the '90s.

The rule was simple: no line longer than 76 characters. If your email line exceeded that, the system would insert a "soft line break"—an equal sign followed by a carriage return and line feed (=\r\n). When the receiving email client decoded this, it would strip out those characters and reassemble the original line. In theory.

Different operating systems had different opinions about how to signal the end of a line. Unix used \n (line feed). Classic Mac used \r (carriage return). MS-DOS, being MS-DOS, used both: \r\n. Internet protocols sided with Microsoft on this one, which is why HTTP and email standards both use \r\n as the line separator.

Where Microsoft Enters the Chat

The video creator, working through a technical explainer by Lars Ingebrigtsen, traces the problem to how Windows handles file I/O. When documents get processed programmatically on Windows machines—which these Epstein files almost certainly were during redaction—there's an underlying method called set_mode that does something helpful: it automatically converts \r\n sequences into single \n characters on input.

This is actually correct behavior. Unix won the line-ending wars eventually. But it creates a problem when those documents contain quoted-printable encoding. What was originally =\r\n (a soft line break that decoders know how to handle) becomes =\n (something decoders don't recognize).

According to Ingebrigtsen's analysis, many email decoders use a two-pass process. First pass: find all \r\n sequences and remove them, joining the lines back together. Second pass: look for equal signs followed by hex codes (like =20 for a space) and decode them.

But when the decoder encounters =\n instead of =\r\n, it doesn't match either pattern. So it does the only "reasonable" thing: removes the \n, leaves the equal sign, and moves on. The video creator notes with appropriate sarcasm: "Yes, what a wonderful fallback mechanism. Makes perfect. Like, if I was a programmer, that's that's what I would do."

The result: "confiden=tial" appears in the released documents exactly where the original email had a soft line break after "confiden" to stay within the 76-character limit.

Why This Matters Beyond Epstein

This isn't just about one document dump. It's about how much of our digital infrastructure rests on text processing decisions made when 80-column terminals were the cutting edge. The video creator points out that HTTP 1.1, which has origins in the 1980s, was only recently replaced by a binary encoding version (HTTP/2). "It only took like 30-some years," he notes.

Every time you see something weird in a digital document—strange spacing, random characters, formatting that makes no sense—there's a decent chance you're looking at the fossil record of some 1990s compatibility decision. Email systems still carry SMTP commands that reference physical printers. Modern web development still deals with MIME types. Git users still have to think about CRLF settings.

The video creator mentions another possible culprit: "There was a small chance that the Epstein files were in fact not on somebody's desk. They are actually in a version control system known as Git, and they just happened to have auto CRLF on, which will convert any CRLF into just a LF." Git's autocrlf setting, designed to prevent line-ending chaos when developers on different operating systems collaborate, could have triggered the exact same cascade.

The Actual Threat Model

From a security and records management perspective, this is concerning for reasons that have nothing to do with hidden codes. When government agencies process and release documents programmatically, they're transforming the original artifacts. Every transformation is an opportunity for data loss or corruption that's invisible to the human eye but potentially significant.

Did the processing pipeline alter timestamps? Did it modify metadata? Did it change how searchable the documents are? We don't know, because we're looking at output from a black box. The equal signs are visible evidence that something in the pipeline didn't handle the input correctly. What else didn't it handle correctly?

This isn't about malice. It's about technical debt. Somewhere in the government's document processing infrastructure is a system that doesn't properly decode quoted-printable encoding. That system probably handles thousands of document releases. How many of them have similar silent corruption?

What Gets Lost in Translation

The equal sign mystery reveals something about how we process information in 2026. When people see patterns in data, they assume intention. Secret codes. Hidden messages. The idea that the pattern might be noise—an artifact of how the data was stored, processed, or transmitted—requires technical knowledge most people don't have.

This asymmetry creates opportunity for both conspiracy theories ("the equal signs are a code!") and for actual malfeasance to hide in plain sight. If everyone expects documents to look a little weird after processing, no one questions whether they should look that way.

The Epstein files matter because of their content, not their formatting. But the formatting tells us something about the systems we trust to preserve and present evidence. Those systems are held together with protocols from 1996, file I/O behavior from MS-DOS, and decoder fallback logic that someone wrote decades ago without imagining it would still be running in 2026.

It's always shocking, as the video creator says, "to discover how much of our life is predicated based on some weird '90s text processing algorithm." The equal signs are just the part we can see.

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.