PowerPoint to PDF

This page reads your .pptx file, draws each slide at its real dimensions, and writes a one-slide-per-page PDF — inside your browser, with no upload. Text stays selectable and searchable. Before converting it inspects the deck and names what it cannot draw, because a slide that comes out blank is worth knowing about in advance.

Slides are easier to convert than documents, which surprised us

The usual assumption is that presentations are the hardest of the three Office formats to convert. Building this changed our mind. A slide is absolute positioning: every shape carries its own offset and extent, so there is no text flow to compute, no line breaking across pages, no pagination logic at all. A Word document, with its wrapping, page breaks and table height calculations, is the harder layout problem by a comfortable margin.

The real difficulty in a .pptx is somewhere else entirely: inheritance. A shape on a slide often has no position, no colour and no font of its own. It says "I am the title placeholder", and the actual values live in the slide layout, and if not there, in the slide master, and the colours in that master are indirections into the theme. Skip that chain and a slide with a heading and three bullets becomes a blank sheet of paper.

We measured what that costs. Across eight real PowerPoint files — genuine Microsoft Office output, verified by the producer string inside them — resolving layout and master inheritance took five of them from between zero and thirteen per cent of their text to one hundred per cent. One deck with a custom master went from a completely blank page to a complete one. The whole feature costs about 10 KB of compressed code.

A lesson from this build: zero often means "automatic"

OOXML uses 0 as a sentinel far more often than you would expect, and JavaScript makes that trap worse because the string "0" is truthy. A table row written as h="0" does not mean a zero-height row; it means PowerPoint should size it automatically. Read it with a plain truthiness check and every row of the table collapses onto the same line, and the shaded header disappears with them because it also has no height.

The same pattern bit us four separate times in one build. A text box with extent zero and an auto-fit flag is an automatically sized box, and treating it as a zero-height box lost twenty-nine paragraphs of body text. A connector line with zero width or height is a horizontal or vertical line, not an invisible one. An attribute reading showMasterSp="0" means "do not draw the master decorations", the opposite of what a truthiness check concludes. Bold written as b="0" means explicitly not bold, which is a real instruction when the style being inherited from is bold.

Every one of those produced output that passed a naive check. The file existed, the page count was right, no error was thrown, and the text layer was largely correct. They were caught by rendering the PDF back to pixels and looking at it beside the reference — which is now how every one of these tools is verified.

What comes out well, and what will be missing

Text and its formatting come out well: titles, bullets at multiple levels with their real bullet characters, per-run bold, italic, underline, colour and size, alignment, line spacing, and the theme fonts resolved down to a serif, sans or monospace choice. Tables come out with borders and header shading. About forty shape types are drawn with correct geometry — rectangles, rounded rectangles, ellipses and circles, triangles, diamonds, parallelograms, polygons up to twelve sides, stars, arrows, callouts and flowchart symbols — along with custom paths, rotation, solid fills resolved through the theme, line colours and widths, and pictures in PNG and JPEG. Slide backgrounds and master decorations are drawn.

Charts are not converted. A chart renderer is a separate graphics engine — axes, scales, legends, series types — and a chart that is half right is more dangerous than a blank space, because it looks like data. SmartArt is drawn from the fallback picture PowerPoint stores inside the file, which keeps the shapes and text but not the layout engine's finesse; if that fallback is absent, the area is blank. Gradients become the average of their colour stops. Shadows, glows, reflections and 3D effects are not output. Animations, transitions, embedded video and audio are not in a PDF at all, which is a property of the format rather than a limitation of this page. The remaining shape types in the DrawingML specification are approximated with a rectangle: right position, right colour, wrong outline.

You are told which of these apply to your deck the moment you pick it. The page counts the charts, the SmartArt, the gradients and the unsupported shapes in your specific file, measures how much of it is images and video, and lists what it found — in a few milliseconds, before anything is converted.

Chinese text, and the case where we say no

Chinese on a slide needs a font embedded in the PDF, since the built-in PDF fonts are Latin-only. We ship a 6,403-character subset of Noto Sans TC, fetch it only after you choose a file and only if the deck needs it, then subset it again to the exact characters used before embedding. Titles are where this shows up most, and a title rendered as question marks is the most visible possible failure.

That failure taught us not to trust fidelity numbers. One real Japanese deck measured 92.2% of its text preserved and an ink ratio of 1.677 against the reference. Both numbers looked fine. The slide read ????尾崎、淡??最期 — the kana were question marks. Nothing in the numbers said so; we saw it by looking at the rendered page.

So we detect it instead. Japanese and Korean are refused with the reason stated, and the reason is not file size. Noto Sans TC contains none of the 11,172 Korean syllable characters — not a subset choice, an absence — and a real Korean sentence renders at 9.5% even with the complete source font. For Japanese, adding kana would leave common Japanese-only kanji at 69.9%, so the page would be half right, and half right is harder to explain than a clear refusal. Adding a little kana would also do a second kind of damage: our detector would stop warning about those decks while the output stayed broken. We tested that specific outcome, and it is why the bundled set stops where it does.

Nothing is uploaded, and what the licence means for your PDF

Your deck is read with the browser file APIs, converted in the same tab, and the PDF is assembled in memory. No request carries your presentation, so there is no upload to intercept, no retention policy to trust and no download link that could be forwarded. Unreleased results, internal strategy, client names and salary bands live in presentations, and the point of doing this locally is that none of it is sent to us — we could not read it even if we wanted to.

Verify it in a minute: developer tools, Network tab, convert a file. You will see the page, its code, and the Chinese font if the deck needs one. The site's Content-Security-Policy limits connections to our own origin, so a request carrying your file would be blocked by the browser regardless of what the code tried to do.

The bundled font is Noto Sans TC under the SIL Open Font License 1.1, shipped with its licence text. Section 5 of that licence says the obligation to remain under it does not extend to documents created with the font, so your PDF is unencumbered even though a font subset is embedded in it. One thing we do not claim: this is not PDF/A output and not an archival tool — Latin text uses the standard PDF fonts, which are not embedded, and that alone puts the file outside the standard.