The jsonformatter.org Breach Is a Warning for Every PDF Tool

What happened in the breach

On November 25, 2025, The Hacker News published a report titled "Years of JSONFormatter and CodeBeautify Leaks Expose Thousands of Passwords and API Keys." The article — at thehackernews.com — described how researchers harvested over 5 GB of enriched, annotated JSON data captured from two of the internet's most-used developer tools: jsonformatter.org (covering five years of content) and codebeautify.org (covering one year). The dataset spanned more than 80,000 files.

What the dataset contained is the part that should alarm anyone who has ever pasted operational data into a free online tool:

• Usernames and passwords
• Repository authentication keys
• Active Directory credentials
• Database credentials
• FTP credentials
• Cloud environment keys
• LDAP configuration information
• Helpdesk and meeting-room API keys
• SSH session recordings
• Personal information across multiple regulated sectors

The affected sectors named in the reporting span critical infrastructure, government, finance, banking, telecommunications, healthcare, technology, retail, aerospace, education, travel, and cybersecurity. This was not a niche developer tool failure — it was a cross-industry credential leak that pulled production secrets from regulated organizations.

To confirm the data was being actively exploited, the researchers seeded fake AWS access keys into the platforms. Within 48 hours they observed exploitation attempts against the seeded credentials. Attackers were actively scraping the platforms and testing harvested keys against real cloud infrastructure. Both jsonformatter.org and codebeautify.org disabled their save functionality in September 2025 after the researchers alerted affected organizations.

The root cause was architectural

The Hacker News article identifies the technical root cause clearly: predictable URL formats combined with a Recent Links page that enumerated shared content. The two URL schemes were:

  https://jsonformatter.org/{id-here}
  https://codebeautify.org/{formatter-type}/{id-here}

The {id-here} was sequential or otherwise enumerable. There was no authentication on the shared links, no per-user access control, no rate limiting against mass crawling, and the Recent Links page provided a starting set of valid IDs to expand from. Anyone with a web browser and a script could iterate the address space and pull down whatever the original users had pasted.

None of these decisions was malicious. Each one — sequential IDs, share-by-URL, a Recent page for discoverability — looks reasonable in isolation. The failure was the combination plus the fact that user pastes routinely contained production secrets. The operator's privacy posture relied on no attacker noticing the share-URL pattern, an assumption that did not hold for five years.

Generalize to every server-side PDF tool

Now substitute "PDF" for "JSON" in that root cause description. A server-side PDF tool accepts user uploads on a server, processes the uploads on the server, and usually offers some form of share-by-link or temporary-download URL for the processed output. The data class is different — PDFs containing bank statements, contracts, medical records, KYC scans, regulatory filings, M&A working files — but the architectural shape is the same:

• User content is held on operator infrastructure during processing.
• Operator chooses retention period via privacy policy.
• Operator may issue share URLs or download URLs that are guessable or enumerable.
• Operator may maintain a Recent or History page for convenience.
• Operator may log file metadata, content fingerprints, or full bodies for service operations.

Every one of those bullets is a place where the jsonformatter and codebeautify failure could repeat with PDFs instead of JSON. A predictable download URL on a PDF compress tool exposes whatever PDF the upstream user just uploaded. A Recent Documents history page on a server-side PDF editor lets enumeration start from a known valid set. Retention policies that nobody reads turn last week's bank statement into this week's data-breach incident.

For the architectural argument expanded with more failure-mode detail, see our companion post on why server-side PDF tools leak data. For the original framing of how jsonformatter applied specifically to API-key paste habits, see never paste API keys into a JSON formatter.

Failure modes server-side PDF tools share with jsonformatter

Three failure modes are documented in the jsonformatter incident and apply directly to PDF tools that share the same architecture:

1. Predictable share or download URLs

jsonformatter's URLs were enumerable. A server-side PDF tool that produces a short URL for the processed output — common for "get the download link" features and for one-click sharing — is subject to the same risk if the URL is guessable without authentication. Long random IDs help; cryptographic share tokens help more; per-user authentication required to access any output is the only structural fix. Many free PDF tools skip all three for the sake of frictionless UX.

2. Convenience pages that enumerate prior work

jsonformatter had a Recent Links page that gave attackers a starting list of valid IDs. A PDF tool's Recent Documents or History page does the same thing for the operator's stored content. Even if individual documents require authentication, an enumeration of recent IDs leaks the existence and timing of user uploads — a side channel that has its own intelligence value.

3. Retention policies the user never sees

Most free server-side PDF tools list retention windows in their privacy policy (one hour, two hours, 24 hours, 30 days). Few users read these. The retention is the breach surface — whatever is stored for that window is what an attacker can potentially exfiltrate if the storage is compromised. The Hacker News report on jsonformatter showed five years of retention captured in a single harvesting run. PDF tools with weeks or months of retention are smaller targets in time scale but the same kind of target.

The browser-local alternative

The alternative is browser-local processing — running the PDF operation entirely inside the user's browser tab using WebAssembly, with no server in the processing path. That is the model at pdfmavericks.com.

What that means in practice:

• The PDF is read from your disk via the File API into the browser tab's memory. No upload request fires.
• The operation runs inside a WebAssembly module that the tab loaded once from a CDN. The module is the same library (pdf-lib, qpdf, MuPDF, or Tesseract for OCR) that drives a lot of server-side PDF infrastructure, recompiled to run in the browser.
• The processed PDF is written back to disk via the browser download API. The in-memory copy is discarded when you close the tab.
• No share URL is generated. No Recent Documents page exists. No retention window applies because no server-side asset was created.

The jsonformatter failure modes do not apply because there is nothing to enumerate. There is no share URL because the file never left the user's tab. There is no Recent Documents page because the operator does not see what the user processes. There is no retention policy because there is no retention. The five-year window of captured content that the researchers harvested from jsonformatter does not have a PDF-Mavericks-equivalent because the corresponding content was never on a pdfmavericks.com server in the first place.

Verification: open pdfmavericks.com/all-tools, pick any tool, open the browser developer tools, switch to the Network panel, clear it, drop a PDF onto the tool, and run the operation. The Network panel should show only the CDN GETs that loaded before you started — no POST or PUT request carrying the PDF as payload. If one appeared, the file would have been uploaded. It does not appear, because nothing is uploaded.

What to do if you have already used a server-side PDF tool

If you have routinely uploaded sensitive PDFs to a server-side tool, the response is the same playbook any incident-response team uses for a possible exposure:

1. List what was uploaded. Roughly inventory the document categories — bank statements, contracts, KYC scans, medical records, payroll registers — and approximate count over the past 12 months.
2. Read the operator's privacy policy. Note the retention window. Anything within that window may still be on the operator's infrastructure. Anything older was retained or purged according to whatever the policy stated.
3. Treat any credentials in the uploaded PDFs as potentially exposed. If the PDFs contained API keys, passwords, account numbers, or tokens embedded in the document text, rotate them. The jsonformatter incident specifically captured credentials embedded in pasted JSON — the same risk applies to credentials inside PDFs.
4. Document the activity in your internal log. Under GDPR Article 33 (notification of personal-data breach to the supervisory authority) and the DPDPA 2023 Section 8 obligations for data fiduciaries, the uploaded PDF processing may need to be characterized as third-party data processing without a DPA. That is an audit-trail entry, not necessarily a public disclosure — talk to your DPO or legal team.
5. Switch routine handling to browser-local tools. For the ongoing workflow, the pdfmavericks.com catalog covers most common operations without creating new uploads. For the umbrella view of what is available browser-locally, see browser-only PDF editor: no upload, no account.

None of this requires panic. The jsonformatter incident took five years to harvest; most organizations have time to migrate routine PDF handling to a local-first workflow before any specific server-side tool they have used is compromised. The point of the November 2025 disclosure is that the architectural pattern has been proven to fail at scale — not that any specific server-side PDF tool is about to leak in the next 24 hours.

Closing

Server-side file processing is the architecture that produced the jsonformatter and codebeautify breach. It is also the architecture that produces every free-online-PDF-tool retention policy users have to take on faith. Both arrangements ask the user to trust a future operator decision about retention, access control, share URL safety, and incident response. Sometimes those decisions go right for years; sometimes they go wrong for years and the evidence shows up in a Hacker News story.

The structural fix is to remove the server from the path. Browser-local PDF tools do that by design. The November 2025 incident is the proof that the structural fix matters — not because every server-side tool is bad, but because the failure mode that took down jsonformatter is repeatable on any tool that shares its shape. PDF documents carrying financial, medical, legal, and personal data are exactly the wrong place to bet on a server-side operator getting every decision right for the next five years.

For the corresponding regulatory framing under EU GDPR, see our redact PDF for GDPR compliance post. For the safest password handling on a bank-statement PDF, see safest way to remove a PDF password.