You know that moment when you're building something and hit a wall that every reasonable part of your brain says should already be solved by now?
That was me, three weeks ago, staring at an HTML component with tabs.
Not some exotic, over-engineered UI. Just tabs. The kind every front-end dev builds on their lunch break. A nav strip at the top, panels below, click a tab and the content switches. Dead simple. Except I wasn't trying to render it in a browser. I wanted to render it in a PDF.
A little context: what is TreePress?
TreePress is a VS Code extension I'm building that exports any open file to a pixel-faithful, searchable PDF. The entire value proposition is that the output looks exactly like what you see in your editor — same syntax highlighting, same colour theme, same font, same layout. No compromises.
That means when someone opens a file like a styled HTML page or a documentation file that uses tab components, TreePress can't just flatten it. The tabs have to come through. The reader needs to be able to interact with them.
Easy enough, right? ... export the tabs into the PDF.
Turns out: no. Not easy at all.
The brutal reality of PDFs in 2026
I did what any developer does when they hit something unexpected: I googled it. Then I googled it more carefully. Then I read three spec docs I really didn't want to read.
Here's what I found: the PDF specification has no native tab primitive. Not in PDF 1.7. Not in PDF 2.0. Not in any version. Tabs, as a UI element, are not supported in this format.
There are three workarounds that developers have used over the years, and every single one of them has a deal-breaking problem for TreePress:
1. Acrobat JavaScript show/hide fields
You can wire up invisible button widgets as tab headers and toggle the visibility of form field groups. It works — inside Acrobat. But Chrome's built-in PDF viewer ignores Acrobat JavaScript entirely. Firefox support is partial. And even where it works, your tab content has to live inside PDF form fields, which can't hold arbitrary rendered code with syntax highlighting. Non-starter.
2. Optional Content Groups (OCGs)
PDF layers. Put each tab's content on its own layer, set all but the first to hidden by default. The viewer exposes a Layers panel; the user toggles from there. This is the most standards-compliant approach — OCGs have been in the spec since PDF 1.5.
But here's the catch: pdf-lib doesn't support creating OCGs. It's been an open issue in the library for years. Switching PDF libraries just for this feature would mean rewiring a significant chunk of TreePress's post-processing pipeline. A huge change for a feature that still exposes a Layers panel to the user rather than the actual tab UI.
3. Just flatten it
Pick the "default" tab, render that content, and forget the others exist. Simple. Fast. Also, completely wrong for a tool whose entire pitch is fidelity.
I was stuck. Genuinely stuck. The stuck where you close the laptop, make coffee, and stare at the wall for a bit.
The insight that changed everything
On that wall-staring coffee break, I started thinking about what PDFs can do rather than what they can't.
Strip away everything fancy, and every PDF viewer that has existed since the early 90s supports exactly two universal primitives:
Drawing. You can paint rectangles, lines, and text directly onto a page's content stream. These aren't annotations — they're baked into the page itself, visible everywhere, always.
GoTo link annotations. A rectangular hotspot on a page that, when clicked, jumps to a named destination elsewhere in the document. This has been in the spec since PDF 1.1. Chrome supports it. Firefox supports it. Safari supports it. Acrobat supports it. Every PDF reader you've ever used supports it.
And that's when it clicked: I don't need the PDF to understand tabs. I need the reader to feel like it's switching tabs.
What if tabs weren't a feature of a single page, but a navigation metaphor spread across pages?
TSAN: Tab-Strip Anchor Navigation
That's the core of what I ended up building. I called it TSAN — Tab-Strip Anchor Navigation — because naming things helps you think about them clearly.
The idea works like this:
Phase 1 — Detect.
Before rendering anything, TreePress scans the live Puppeteer page for tab patterns. ARIA role="tab" attributes, Bootstrap .nav-tabs, Material .mat-tab, custom data attributes — anything that looks like a tab gets detected and registered as { label, activatorSelector, panelSelector }.
Phase 2 — Capture.
For each tab, TreePress force-activates it (programmatically clicks the activator and waits for the render to settle), then injects a CSS padding reservation at the top equal to the height of the strip we'll paint later. Puppeteer prints that tab's content to its own mini-PDF. We record which pages belong to which tab in a registry.
Phase 3 — Assemble.
All the per-tab PDFs get merged into a single document in order. Now we have a regular multi-page PDF with pages 1–3 as "Tab A content", pages 4–6 as "Tab B content", and so on. The tabStartPages[] array stores the starting positions of each tab.
Phase 4 — Decorate. (This is the invention.)
Now TreePress walks every page of the assembled document and paints a tab strip on it using only those two universal primitives.
For the active tab (the one that owns the current page), it draws a filled pill and a coloured accent line beneath the label. For every other tab, it draws a plain label — and places a GoTo link annotation on top of it, pointing to the first page of that tab's content.
The result: every page has a persistent, drawn tab strip at the top. Clicking any non-active tab label jumps to the start of that tab's page range. The PDF has no JavaScript, no layers, no form fields. Just rectangles, text, and link annotations — things every viewer has understood since 1993.
What it actually looks like
Open the exported PDF on any reader — Chrome, Firefox, Safari, Acrobat, Google Drive, Document Viewer on Linux, whatever you have. You see:
A tab strip across the top of every page, styled to match the source UI
The current tab is visually highlighted with a pill and accent line
All other tabs are clickable, jumping instantly to their page range
The tab strip is rendered as drawn content, meaning it's always visible — no settings to toggle, no layers panel to find
It doesn't behave identically to a JavaScript tab switcher in a browser. It's more like a well-indexed book: you flip to a section, and everything on that section's pages tells you which section you're in. That's actually a more natural mental model for a PDF anyway.
Why this matters for TreePress
TreePress exists because every existing "code to PDF" tool treats code as plain text. They dump a monospace font onto the page and call it done. The whole point of TreePress is that the output should feel like you took a screenshot of VS Code and made it searchable and printable.
TSAN extends that philosophy to interactive UI. It doesn't fake tabs. It doesn't flatten them. It translates the tab experience into the PDF medium without requiring anything from the reader that isn't already there.
This is the kind of problem I find genuinely exciting: a constraint that appears to be a dead end and turns out to be a design opportunity. The PDF format isn't broken; it just doesn't think in terms of HTML widgets. TSAN is TreePress learning to speak PDF natively.
The module is open
The tabStripRenderer.ts module that powers this is being published with the TreePress extension. If you're building anything that involves rendering HTML with tabs into PDF — documentation tools, report generators, anything — the approach is directly reusable.
The four-phase pipeline (detect → capture → assemble → decorate) works independently of the VS Code extension machinery. You need Puppeteer for phases 1 and 2, and pdf-lib for phases 3 and 4. That's it.
If you've ever hit this wall — "I need to get interactive HTML into a PDF, and everything I try is broken" — I hope this gives you a usable path forward.
The PDF format is older than most of the developers reading this. It's occasionally infuriating. But it's also remarkably consistent, and consistency is something you can build on.
TreePress is a VS Code extension — open it in the Marketplace under treepress.vscode-treepress. TSAN is part of the V2 release.
Found this useful? Drop a like or follow.
Top comments (0)