A Short History of PDF Games: From Form Scripts to Doom and Linux

The story of PDF games is a story of a feature that outlived its original purpose. JavaScript went into PDF so that forms could calculate totals and check dates. For years that's mostly what it did — that, and help attackers break into computers. Then a small group of programmers started treating PDF viewers as an unusual, very limited game console.

The 1990s: PDF gets a scripting language

Adobe released PDF in 1993 as a way to share documents that look identical on every machine. Interactive forms came a few years later, and in the late 1990s Adobe added JavaScript to Acrobat so forms could react to what you typed. JavaScript actions became part of the PDF specification around version 1.3, released alongside Acrobat 4 in 1999. Exact milestones differ depending on whether you count Acrobat's plug-ins or the published spec, but by the turn of the century scripted PDFs were routine in government and business forms.

Adobe's API gave scripts access to the viewer (app), the document, its fields and events. Crucially for later game makers, it included timers — app.setInterval and app.setTimeOut — intended for things like auto-saving or animated form hints.

The 2000s: the malware era

As Adobe Reader became installed on nearly every computer, its JavaScript engine became a target. Through the late 2000s, attackers used bugs in Reader's built-in JavaScript functions to run code just by getting someone to open a PDF attachment. It's a large part of why PDF scripting has a bad reputation and why security advice long recommended disabling JavaScript in Reader.

Adobe responded with a sandboxed Protected Mode in Reader X (2010) and tighter controls. Browsers, meanwhile, began building their own PDF viewers that ran scripts — if at all — inside the browser's sandbox. That shift is what made PDF games safe to play in a web page.

The 2010s: browsers get their own PDF engines

Mozilla started PDF.js, a PDF renderer written in JavaScript, which became Firefox's built-in viewer. Google shipped a PDF viewer in Chrome and in 2014 open-sourced its engine as PDFium. PDFium included a scripting layer implementing a meaningful subset of Acrobat's JavaScript API — enough for forms, and, as it turned out, enough for games.

Around 2020: Breakout and PDFtris

The project that made PDF games famous was Omar Rizwan's horrifying-pdf-experiments, a playable Breakout in a PDF built for Chrome, published around 2020. Its most cited trick was mouse tracking: since scripts can't read the cursor position, Rizwan covered the playfield with hundreds of invisible, one-point-wide text fields and used their mouse-enter events to work out where the pointer was.

Thomas Rinsma's PDFtris showed the format could handle a complete, tightly controlled game too: Tetris, rendered as a grid of form fields toggled on and off, controlled by typing W, A, S and D into a text box. Both projects published their source code, and both became go-to references for anyone trying the same thing.

Others followed with smaller games — Flappy Bird clones, checkers, calculators — many shared anonymously, passed around as single files, their authors lost along the way.

January 2025: Doom, inevitably

Doom has a long tradition of being ported to unlikely hardware, so a PDF port was a matter of time. In January 2025 developer ading2210 released DoomPDF. It compiles doomgeneric — a portable version of the DOOM source — with Emscripten into JavaScript that PDFium can execute, and renders each frame as rows of ASCII characters written into text fields. It wasn't the first time someone had thought about it, but it was a complete, playable release, and it spread widely.

2025: LinuxPDF

The same developer then went further with LinuxPDF: a PDF that boots a Linux kernel by running a RISC-V emulator compiled to JavaScript, again drawing its console output with form fields. It isn't a game, but it settled any argument about what a PDF viewer can compute given enough patience. It also renewed interest in PDF scripting as a playground, which is roughly where PDFGame comes in.

Security, then and now

PDF scripting still occasionally makes security news. In 2024, Thomas Rinsma disclosed CVE-2024-4367, a PDF.js bug that let a crafted file run arbitrary JavaScript in the viewer's context; Mozilla fixed it quickly. The modern picture is much better than in the Reader era: browser viewers expose a narrow API and run inside the browser's sandbox, and the games people make use nothing more exotic than timers and form fields.

Timeline at a glance

• 1993 — Adobe releases PDF and Acrobat.
• Late 1990s — JavaScript arrives in Acrobat forms; JavaScript actions appear in the PDF 1.3 specification (Acrobat 4, 1999).
• Late 2000s — Exploits in Adobe Reader's JavaScript functions make malicious PDFs a common attack.
• 2010 — Adobe Reader X introduces a sandboxed Protected Mode.
• 2014 — Google open-sources PDFium, Chrome's PDF engine.
• Around 2020 — Omar Rizwan's Breakout and Thomas Rinsma's PDFtris popularise PDF games.
• 2024 — CVE-2024-4367 in PDF.js is disclosed by Thomas Rinsma and patched.
• January 2025 — DoomPDF by ading2210.
• 2025 — LinuxPDF boots Linux inside a PDF.

Why people keep doing this

There's a long hacker tradition of running games where they don't belong: Doom on printers, thermostats and tractors; Tetris on oscilloscopes and building facades. The point isn't a better way to play — it's the puzzle. Each platform has a different minimum set of capabilities, and finding that minimum teaches you more about the platform than its documentation does.

PDF is a particularly satisfying target because it's so ordinary. Everyone has opened thousands of PDFs; very few people know they can contain a timer and an event system. A playable game hidden in something that looks like a boring document is a good joke and a good lesson about what file formats can carry.

The preservation problem

Many small PDF games circulated as single files on forums and chat apps, often without a name, licence or author. A PDF is self-contained, which is great for sharing and terrible for attribution: once the file has been forwarded a few times, nobody knows where it came from. Several games in our own collection fall into that category. When we know who made a game we link to them and their source code; when we don't, we say so and invite the author to get in touch.

Viewer changes are the other risk. PDF games depend on undocumented details of how PDFium or PDF.js behave, and an update to either can break a game overnight. Keeping downloadable copies and source code around is the best insurance a small genre like this has.

Today: a small, strange genre

PDF games are still a niche. They're slow, they don't work on phones, and most people have never heard of them. But they keep appearing because they're a genuinely fun constraint, the same impulse that puts games on calculators and oscilloscopes. PDFGame collects them in one place, credits their authors where we know them, and adds a few originals of our own — Snake, Minesweeper and 2048, each built as a real scripted PDF you can download and pick apart.