Paper2Slides: turning a PDF paper into slides or a poster from the command line

The gap Paper2Slides fills: paper in, deck out

Most paper-to-deck work is mechanical. You read the abstract, pull the figures, decide what fits on a slide, and retype it. Paper2Slides targets that loop directly: the README describes it as turning research papers, reports and documents into slides and posters, with PDF, Word, Excel, PowerPoint and Markdown listed as inputs, and multiple files accepted at once.

The intended user is someone who already has the paper and needs a presentation artefact from it, not someone building slides from an outline. The repository topics (agentic-ai, llm-agents, paper2poster, paper2slides) point at the same audience. Note the default output type in the CLI table is poster, not slides, so a first run without --output gives you a poster even though the project name says slides.

What it is not: a slide editor. Nothing in the README describes editing an individual text box or moving a figure after generation. The unit of control is the stage, the style string, and the length or density setting.

How the pipeline works: four named stages and a checkpoint file

The architecture is visible in the --from-stage option, which accepts exactly four values: rag, summary, plan, generate. That ordering is the data flow. The RAG stage indexes the input document. The summary stage condenses it. The plan stage decides the slide or poster structure. The generate stage renders images.

Because those stages are named, the checkpoint system is not a vague promise. The README states checkpoints are auto-saved at every key stage and that re-running the same command resumes by auto-detection. Restarting from a specific stage is the explicit override. The practical consequence is that a style change does not require re-indexing: the README's own table pairs "Change style only" with --from-stage plan, and "Regenerate images" with --from-stage generate, which keeps the existing plan.

--fast is the shortcut that skips RAG indexing. That is a real trade-off, not a speed dial: skipping indexing means the content-extraction step that the README ties to source-linked accuracy is not run. For a short paper you already know well, that may be fine. For a long document with figures you care about, it is the part you probably want.

--parallel accepts either a bare flag (2 workers) or a count, and the release notes date it to 2025.12.09, after the 2025.12.08 open source release. Parallelism applies to slide generation, so it shortens the last stage, not the indexing stage.

Installing Paper2Slides and generating a first deck

The README gives a conda-based setup with Python 3.12. Clone the repository, create the environment, and install from requirements.txt. The dependency list includes lightrag-hku for the RAG core, mineru[core] pinned at 2.6.4 for document parsing, and openai for API access, so the index of the first run depends on those installing cleanly.

git clone https://github.com/HKUDS/Paper2Slides.git
cd Paper2Slides
conda create -n paper2slides python=3.12 -y
conda activate paper2slides
pip install -r requirements.txt

Before the first real run you need credentials. The README instructs you to create a .env file in the paper2slides/ directory and points at paper2slides/.env.example for the required variable names. The README does not list those names, so read the example file rather than guessing.

cd paper2slides
cp .env.example .env
# edit .env and fill in the variables listed in the example file

Then run the documented one-liner. This example comes straight from the README, including the style name and the parallel count.

python -m paper2slides --input paper.pdf --output slides --style doraemon --length medium --fast --parallel 2

Expect a slides artefact written under the output location, plus a checkpoint that a second identical invocation will pick up. To see what has already been processed, the README documents a listing command.

python -m paper2slides --list

If you only want a poster, drop --output slides and use --density instead, which takes sparse, medium or dense. A custom look is a natural-language string rather than a theme file; the README's own example is a Studio Ghibli description passed to --style. The web interface is a separate path: scripts/start.sh launches backend and frontend together, and the api/ directory holds a FastAPI service with uvicorn.

Where Paper2Slides breaks down

The output is generated imagery. The README describes professional-grade visuals and presentation-ready slides, but it does not describe an editable intermediate format, so a deck that gets the structure right and one figure wrong still means either accepting it or restarting from a stage. The finest documented control is --from-stage generate, which regenerates all images while keeping the plan.

Style is a free-text prompt. That is flexible and also unstable: the same description can produce different results across runs, and the README offers no seed or determinism control. If your institution has a fixed template with a logo in a fixed corner, this is the wrong tool, because nothing in the README describes template locking.

--fast removes the RAG indexing step. The README presents it as fast mode, and the CLI table is explicit that it skips RAG indexing. Anyone who reads the feature list about comprehensive content extraction and then runs with --fast has opted out of the mechanism behind that claim.

Finally, the pipeline depends on external API keys and on MinerU for parsing. Both are single points of failure that the README does not discuss in terms of retries or offline operation. The README documents stage restarts; it does not document rollback of a completed stage.

Paper2Slides compared with SlideSpeak and Auto-Slides

The related searches around this project name SlideSpeak and Auto-Slides, so the comparison is worth making concrete. SlideSpeak and Auto-Slides are separate products; the README contains no description of their internals, so the honest difference is the one Paper2Slides documents about itself.

That difference is stage decomposition. Paper2Slides exposes rag, summary, plan and generate as named restart points, and it ships a CLI plus a FastAPI backend that scripts/start.sh wires to a frontend. A tool that presents a single generate button has no equivalent of --from-stage plan, which is what lets you swap the theme without paying for re-parsing. Conversely, a hosted product usually owns the rendering quality and the template library, which is the part Paper2Slides leaves to a prompt string.

The other distinction is deployment. Paper2Slides runs locally from a clone, with your own API keys in paper2slides/.env, and the docker/ directory in the repository root indicates a container path exists. That matters if the input papers are unpublished or under review and you would rather not upload them to a third-party service. The README does not describe a hosted version, and the repository has no homepage listed.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-05-20. That is roughly four months before today, which is recent enough that the project is not dormant, but there are no release artefacts and no version tags, so there is no changelog to read before upgrading. The news section is the closest thing: parallel generation arrived on 2025.12.09, one day after the 2025.12.08 open source release.

Upgrade cost sits mostly in the dependency pins. requirements.txt pins mineru[core]==2.6.4, fastapi==0.122, uvicorn[standard]==0.38.0, python-multipart==0.0.20 and pydantic==2.12.3, while the rest are floors (Pillow>=10.0.0, reportlab>=4.0.0, openai>=1.0.0, python-dotenv>=1.0.0, pyyaml>=6.0, requests>=2.28.0). The pinned half is the half that will fight you if you install into an environment that already has a different FastAPI or pydantic. A separate conda environment, as the README shows, avoids that.

Licensing is MIT per the repository and the badge. MIT permits commercial and private use and modification; it also means no warranty. Nothing here is legal advice, and the README says nothing about the licences of the models or APIs you connect through .env, which is where a real review would need to look.

Editorial conclusion

Adopt Paper2Slides if you have a pile of PDFs and need a first-draft deck or poster you can then edit by hand, and if you are comfortable supplying API keys through paper2slides/.env. Do not adopt it if you need pixel-level control over the final file, since the README documents a pipeline with stage-level restarts and theme strings rather than per-element editing. Before committing, verify three things in the repository: the variable names in paper2slides/.env.example, whether the --content general path behaves acceptably on your non-paper documents, and whether the MinerU dependency installs cleanly on your platform, because mineru[core] is pinned to 2.6.4 in requirements.txt.

Frequently asked questions

Official sources

1. HKUDS/Paper2Slides on GitHub
2. Issues
3. License: MIT
4. README