One developer, an editor and its engine
ReflowPDF is a PDF editor in the browser and the HTML-to-PDF engine under it. I build both.
Vlad Kyslenko
Developer from Ukraine, based in the US
Why it exists
I’m 31, I have two kids, and I’ve been writing code since I was 16: fifteen years of full-stack work, the kind of systems where a client always says, at some point, “and we need it to make a PDF.” I moved from Ukraine to the US a few years ago and kept building.
It started with automated multi-page financial reports: a flex-based header, tables that run across pages with their headers repeated, summary blocks that change with the data. Ordinary modern CSS that a browser lays out in milliseconds.
No PDF library I tried could do it, in any language. Python’s WeasyPrint, the most capable I found, had flexbox only partly then, and its tables broke across pages. ReportLab is powerful but has no HTML and CSS: you place everything by hand. Java’s OpenHTMLtoPDF had been archived; iText is commercial, with licensing I could not use. The PHP engines implemented CSS 2.1, and the JavaScript ones drove a headless Chromium.
I spent days on workarounds: absolute positioning instead of flex, page breaks by hand, headers duplicated by hand. The output looked close enough, and the code could not be maintained. So I opened the PDF specification and the source of the libraries I had been fighting, to understand why they failed at the same things.
On the editing side the gap was the same. PDF editors, Acrobat included, edit the lines of a PDF where they are: text can move within its box, not on to the next page, and a table has no row to add (why). Going from positioned text to a document you can edit takes AI that reads a page’s layout, a CSS engine that follows the specifications, and a way to go from PDF to document and back.
How it was built
The missing flexbox was not the real problem. When a flex container crosses a page boundary it has to be split, and the split changes the space left, which changes how the items share it, which moves the next split. Layout, pagination and reflow depend on each other. The libraries I had used treated them as separate steps, and that is where they broke on my documents.
From September 2025 to February 2026 I wrote a layout engine from scratch: flexbox as the specification writes it, every min-size rule and frozen-item pass; tables with column and row spans and header rows repeated across pages; font subsetting, composite glyphs and a ToUnicode map; and pagination that understands flex containers, splits them and lays them out again after the split.
In March 2026 I turned it round. The engine turns HTML into PDF, so AI rebuilds a PDF as a document, you edit it, and the engine makes the PDF again. That became a full editor, with text, tables, templates and pictures, and a switch that keeps the document inside the PDF it exports, so it reopens without AI.
The first engine was PHP, and a 246-page report took 38 seconds. I rewrote it in Rust, on the same specifications and the same architecture, with a typed arena of boxes instead of an object graph; on the same documents that report took 6 seconds. Since July 2026 every PDF on the site is made by the Rust engine, with no PHP left to fall back on, and the same code compiles to WebAssembly, so the editor and the playground run the engine that makes the PDF.
Since November 2026 the test results are published. The engine is judged by the web-platform-tests, the tests browsers are judged by, none of them written by me, and the whole run is published, every failure with its reference and the pixels that differ. On the benchmarks page ReflowPDF, Chrome’s print and Prince 17 print the same tests to PDF. PDFs are checked with veraPDF for PDF/UA-1, PDF/UA-2 and PDF/A-3a, and the files are there to check.
Why an editor and not a converter
An AI tool that converts a document and hands you the result leaves you with whatever it got wrong. A complex page will not come out perfect, so the useful result is one you can correct. That is why ReflowPDF is a full editor and not a converter with a download button: AI rebuilds the PDF, and you fix what it missed with the same tools you write with. Keep the PDF editable when you download, and next time the AI is not involved.
What other libraries taught me
- Input is checked before layout.
- In the libraries I studied, security was often an afterthought: font files accepted without validation, remote resources loaded by default, SVG parsed without protection against external entities. I wrote input checks, URL validation, font signature checks and limits on image decompression before the first layout function.
- Pagination cannot be separate from layout.
- This was the mistake I saw most: lay out once, then cut into pages. It breaks when a container or a table crosses a boundary, because the cut changes the space, which changes the layout, which moves the cut. My engine decides both in one pass.
- No runtime of someone else’s in the path.
- Headless browsers get heavy in production, archived projects leave a dead dependency, licences change. I wrote the style resolver, the layout engine and the PDF writer myself; what comes from others (the HTML parser from Servo, the text shaper, the font subsetter) is open-source code I can read and patch, so when something breaks I can fix it.
- Keep layout and drawing apart.
- Several libraries tie the computing of positions to the drawing of the PDF, which makes a new layout mode a rewrite of the renderer. I kept them in separate layers from the first day; adding flexbox meant adding a layout, and the PDF writer did not change.
Where it stands
A document made in the editor, from a template or from nothing, is laid out by the same engine that writes the PDF, so the download breaks its pages where the editor showed them. The engine was built for long documents from the start.
Importing a complex PDF is harder. A clean invoice or a standard contract comes through well; the more nested the layout (columns inside tables inside flex containers, decoration overlapping text), the more the AI has to guess, and guesses are not always right. I improve it from the documents people send; a heavily layered document may need fixing after import.
Try it on your own PDF.
ReflowPDF is operated by INSEAW LLC, South Carolina, United States. Write to hello@reflowpdf.com.