Burner X: an AI paper reader that runs in the browser tab

A workstation where the document never leaves the tab

Burner X, published under the name Paper Burner X, is a JavaScript application for people with a folder full of unread PDFs. The stated audience is graduate students and researchers, and the stated problem is volume: too many papers, formulas that break when you paste them, and a translation step that mangles layout. Version 2.0.0 in the badge row, AGPL-3.0 in the licence badge, and a homepage at paperburner.site.

The design decision that shapes everything else is where the work happens. The README says all data stays in the browser, stored in localStorage and IndexedDB, and that the tool runs the moment you open the page. There is no account to create in the default mode and no server to operate. That is a different bet from the hosted PDF translators, which need to upload your document somewhere to work on it, and it is the reason the README lists BYOK in the project description: you supply the API keys, the browser makes the calls.

What you get for those keys is a long feature list. Import covers PDF, Markdown, TXT, DOCX, PPTX, HTML and EPUB, and content can also be pulled straight from a GitHub repository or any URL, with code comments treated as importable text. Export goes back out as HTML, PDF, DOCX or Markdown, with images either embedded or linked. On the reading side there is paragraph-level alignment between the original and the translation, a table of contents, character-level highlighting and annotation, LaTeX and table rendering, and a desktop immersive mode. The analysis side adds a chat assistant with streaming output, mind map generation, Mermaid flowchart generation and editing, conversation export to an image, and image upload for multimodal questions.

History lives in IndexedDB and offers original, translation or side-by-side views. There is a caution at the bottom of the README that is worth reading before you trust it: clearing browser data deletes that history, because there is no server copy.

The agent gets grep, vector search and fetch

Most document chat boxes paste your paper into a context window and hope. Burner X takes a different route, and the README is specific about the mechanism. The agent runs entirely in the frontend, and it is given a layered map of the article's structure so the model has an overall sense of the whole document before it answers anything about a part of it.

The tools are the more interesting half. The model receives exact-match `grep`, `vector search` for semantic retrieval, and `fetch` for pulling content, and it decides on its own which combination to call for the question you asked. That is a retrieval loop running client side rather than one giant prompt, and it is why the project can claim to handle long text rather than a fixed number of tokens.

There is also a routing decision. When the text is short, the tool set uses a full strategy; when a long document is supplied, it switches to the long-text agent. The README does not document the threshold that decides between them, so if you are testing where that boundary sits, you will have to find it empirically.

Alongside the agent sit two utilities that pull structure out of unstructured prose. A document matrix extracts papers into comparable structured rows for side-by-side reading, and the glossary system is built for scale: it is described as handling tens of thousands of terms in one import with fast matching, injecting those terms into the translation prompt so a term stays translated the same way across a whole book. Folder batch import preserves directory structure, and configurable concurrency for both document processing and translation is what makes a long paper finish in seconds rather than minutes.

Deploying the frontend build is a fork and one import

There are two deployment modes, and only one of them is finished. Mode 1 is the pure frontend, which the README recommends for individuals, and the steps are short enough to reproduce. You fork the repository, import the fork at vercel.com/new, and click Deploy. The online demo the README points at is at paperburner.viwoplus.site, and there is a separate landing page under views/landing in the tree.

The root `package.json` is deliberately thin. It is named `paper-burner-root`, marked private, and its only dependency is vite at ^5.4.0, with three scripts:

"scripts": {
  "dev:fe": "vite",
  "build:fe": "vite build",
  "preview:fe": "vite preview"
}

That the `postinstall` hook prints `No frontend build by default. Use npm run build:fe if needed.` tells you something useful: a plain install does not produce a bundle. If you are running locally rather than on Vercel, `npm run dev:fe` is the command, and `vite.config.js` sits at the root next to `vercel.json`.

Mode 2 is Docker, and here the README contradicts itself in a way that costs you time if you skim it. Near the top of the file, under the screenshot, a note says the backend version is still being built and tells you not to pull the Docker image yet. The Docker section then gives a pull command and links `deploy/DEPLOYMENT_GUIDE.md`. The roadmap at the bottom ticks Docker deployment support, multi-user accounts and the admin panel as done. The mode 2 heading itself says the mode is coming soon. So the artifacts exist, the checklist says finished, and the prose says wait. Assume the compose stack needs work before it will run unattended.

The image the README points you at is:

docker pull feather2dev/paper-burner-x:latest

One thing to know about the frontend mode: there is no rate limiting and no shared state, but there is also no persistence you control. The keys you paste live in the browser, which is convenient and also means a cleared profile takes your configuration with it.

OCR engines and model keys are yours to wire up

The configuration surface is where this project stops being a viewer and starts being a client for services you pay for separately. `.env.example` at the root enumerates it, and the split is clean: OCR credentials are separate from translation credentials.

Three OCR services are named: MinerU, Doc2X and Mistral. MinerU is also the engine behind the format-preserving translation feature, where the translated output keeps the original layout, formulas and figures rather than flattening them into paragraphs. The README marks that feature as still being optimized and says more models will be supported, which is the single most useful expectation to set if formulas are why you are reading the paper in a second language.

Translation and analysis credentials cover DeepSeek, Google Gemini, Anthropic Claude, Alibaba Tongyi Qianwen, Volcano Engine, plus a custom endpoint option. Three features make that list practical rather than decorative. Model auto-detection calls `/v1/models` on the endpoint and populates what is available. Multi-key rotation cycles through several API keys, which is the difference between a rate limit ending your batch and the batch finishing. Configuration export and import let you move a setup between machines.

There is also a prompt pool mechanism, where AI-generated prompt variants are managed automatically so the core requirement stays fixed while phrasing varies across chunks, and custom translation prompts for when you need to steer it. The environment file shows what the backend expects of the same settings:

DEPLOYMENT_MODE=backend
MAX_UPLOAD_SIZE=100
LOG_LEVEL=info

For the self-hosted OCR path, the project points at a separate repository, PBX-DS-OCR-server, which is the route to take if documents must not leave your network. Note that `MAX_UPLOAD_SIZE` is in megabytes and applies server side, so the 100 MB default does not constrain frontend-only use at all.

What the compose file describes on the backend side

`docker-compose.yml` is the clearest statement of what the multi-user mode is meant to be. It runs two services: a PostgreSQL 16 on Alpine with a named volume and a `pg_isready` healthcheck, and the application built from the repository's own `Dockerfile`, which waits for the database to report healthy before starting.

The database connection and the security settings are all environment driven, which is what you would expect from something meant to run on a server:

DATABASE_URL: postgresql://${DB_USER:-paperburner}:${DB_PASSWORD:-changeme}@postgres:5432/${DB_NAME:-paperburner}
JWT_SECRET: ${JWT_SECRET:-your-super-secret-jwt-key-change-in-production}
ENCRYPTION_SECRET: ${ENCRYPTION_SECRET:-your-encryption-secret-min-32-chars-change-in-production}
RUN_MIGRATIONS: "true"

Read those defaults as a warning rather than a starting point. `changeme` and the two placeholder secrets ship as fallbacks, and `.env.example` marks both secrets as important, suggesting a different value for the encryption key than for the JWT key. Migrations run at startup, which is convenient, and the README's own caution about obeying provider terms applies to the OCR and model calls you make through it.

The `Dockerfile` is a two-stage build on node:20-alpine. The builder installs OpenSSL because Prisma needs it on Alpine, copies the server package files, runs `npm install` rather than `npm ci` with a comment explaining that the lockfile is out of sync and install is used to keep PR builds passing, then generates the Prisma client. The runtime image adds dumb-init, creates a non-root user at uid 1001, normalizes line endings on the entrypoint script so Windows checkouts still produce an executable file, exposes port 3000 and adds a healthcheck against `/api/health` on a 30 second interval with a 40 second start period.

That healthcheck path and the presence of `server/`, `admin/` and `login.html` in the tree confirm the multi-user shape: authentication, an admin surface and a server-side history, all of which the frontend-only mode does without. Nginx appears in `.env.example` with `NGINX_PORT=80` and `NGINX_SSL_PORT=443` for termination in front of the app.

AGPL-3.0, inherited code, and what the dates tell you

The licence is the part to read carefully before you deploy this. Burner X is AGPL-3.0, and the README spells out the consequence in its own section: if you run it as a network service, including a public web service, a SaaS platform or an internal company service, you must put a source code link in a visible place in the user interface, that link must give users the complete source for free, and it must include your modifications. For an internal tool that is the part people miss.

The lineage matters too. The project is derived from the idea behind Paper Burner by Baoyu, which is GPL-2.0. The README splits the copyright: AGPL-3.0 covers the current code, described as mostly newly written after a refactor, while the pre-refactor code tied to Mistral translation and parts of the UI remain under GPL-2.0, with the boundary dated to before May 16, 2025 in the git history. A `NOTICE` file sits at the root alongside the licence. The README also points readers who want something lighter back to the original Paper Burner, which is a GPL-2.0 minimal PDF translation tool.

On the numbers: 1,762 stars, 762 forks and 8 open issues, with no tagged releases published at all. The last push was 2026-03-09. Read together with the roadmap, that picture is a project with real adoption and a version number in the badge row that is not attached to any release artefact you can install, so pinning a tag is not an option and pinning a commit is.

The honest limitation is the split between the two halves. The frontend is finished enough to be genuinely useful on its own, with the agent, the OCR pipeline and the glossary all working in the browser. The backend, which is where shared accounts, server-side history and the admin panel live, is described as under construction in the same file that ticks those boxes. Anyone planning an institutional deployment is committing to the compose path before it is ready.

Editorial conclusion

Burner X is worth a look if your reading pile is mostly papers and you already pay for at least one OCR service and one translation model, because the frontend-only mode needs nothing else: a fork, a Vercel import, and keys typed into the browser. It is the wrong shape for a team that needs shared accounts, because that is the half the README warns is still under construction and the half the compose file is written for. Start with the frontend mode, import one paper you know well, and turn on the `/v1/models` check before you assume your endpoint works. Read `deploy/DEPLOYMENT_GUIDE.md` and `deploy/LOCAL_TESTING.md` before touching Docker, and remember the last push was 2026-03-09 with no tagged release, so pin a commit rather than a version if you deploy it.

Frequently asked questions

Official sources

1. Feather-2/Burner-X on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README