DEV Community: PetrDev

Making a screenshot PDF searchable — no OCR, because we rendered the page

PetrDev — Thu, 20 Aug 2026 12:44:24 +0000

We archive whole web pages as PDFs. Under the hood each page is a full-height screenshot dropped onto a PDF page — which looks perfect and is completely useless the moment you want to use the text. Ctrl+F finds nothing. You can't copy a sentence. A screen reader opens the document and sees… an empty page with one big image.

The fix is the same trick a "searchable scan" uses: draw the real text invisibly, on top of the image, at the exact coordinates where each word appears. The difference is that a scanner needs OCR to guess the text — we rendered the page ourselves, so we already have the ground truth. No OCR, no guessing.

Here's how we built it with pdf-lib and @pdf-lib/fontkit, and the one part that turned out to be genuinely hard.

The shape of it

While the page is still open in the headless browser, ask the DOM where every word is.
Assemble the PDF: embed the screenshot as the page background.
For each word, drawText it at its coordinates with opacity: 0.

Steps 1 and 3 are easy. The trap is in which words you're allowed to draw.

Step 1 — ask the browser where the words are

Running inside the page (Puppeteer's page.evaluate), we walk every text node and measure each word with a Range:

const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT);
// ...for each word in each text node:
const range = document.createRange();
range.setStart(node, start);
range.setEnd(node, end);
const rects = range.getClientRects();
if (!rects.length) continue;           // display:none or empty line box
const b = rects[0];                    // first rect = where the word starts
out.push({
  t: word,
  x: b.left + window.scrollX,          // document coordinates, not viewport
  y: b.top  + window.scrollY,
  w: b.width, h: b.height,
  fs: parseFloat(getComputedStyle(el).fontSize) || 12,
});

getClientRects() gives viewport coordinates, so we add scrollX/scrollY to get document coordinates — the ones that line up with a full-page screenshot. A word wrapped across two lines returns several rects; the first is where a search should land, so that's the one we keep.

Step 2 — the hidden-text trap (the hard part)

The naive version above shipped a bug immediately. On a real page, search started highlighting words that weren't in the picture — items inside a collapsed dropdown menu, off-canvas nav, text-indent: -9999px SR-only text. The image showed them collapsed; the text layer had them anyway.

The tempting assumption is "hidden text has no client rects." It's false. Only display: none produces no rects. Every other way of hiding something still reports perfectly good coordinates:

visibility: hidden
opacity: 0
max-height: 0 + overflow: hidden (the collapsed accordion / submenu)
parked offscreen with text-indent: -9999px or a negative position

So each word has to be checked against its whole ancestor chain, not just its own box. We memoise one walk up the tree per element (a deep DOM would otherwise re-read computed styles thousands of times):

function chainInfo(el) {
  if (cache.has(el)) return cache.get(el);
  const above = el.parentElement ? chainInfo(el.parentElement)
                                 : { visible: true, opacity: 1, clips: [] };
  let info;
  if (!above.visible) {
    info = { visible: false, opacity: 0, clips: above.clips };
  } else {
    const cs      = getComputedStyle(el);
    const opacity = above.opacity * (parseFloat(cs.opacity) || 0);   // multiplied down the chain
    const visible = cs.visibility === 'visible' && opacity > 0.05;
    const clips   = /\b(hidden|clip)\b/.test(cs.overflow)
      ? above.clips.concat([el.getBoundingClientRect()])
      : above.clips;
    info = { visible, opacity, clips };
  }
  cache.set(el, info);
  return info;
}

A word survives only if its chain is visible, its multiplied opacity is above a floor, it intersects every clipping ancestor (a zero-height collapsed container clips its contents to nothing), and it isn't parked entirely outside the document box. Clipping is judged on zero intersection, not partial — a word half-cut by a container is still half in the picture, and dropping it would lose real text.

That single ancestor-walk is the difference between "searchable PDF" and "PDF that lies about what's in it."

Step 3 — flip the Y axis

The DOM measures from the top-left; PDF space is bottom-left. So when we draw, Y inverts, plus a small nudge so the selection highlight sits on the glyphs rather than below them:

const y = imageH - b.y - b.h + b.h * 0.2;

Step 4 — the font problem

pdf-lib's built-in fonts are WinAnsi. They can't encode Cyrillic, Greek or CJK — and they even choke on curly typographic quotes, of which there are four on our own English blog. Draw an unencodable glyph and the call throws.

So we embed a real TrueType font, subset to only the glyphs actually used, via fontkit:

const fontkit = require('@pdf-lib/fontkit');
doc.registerFontkit(fontkit);
const font = await doc.embedFont(fs.readFileSync(fontPath), { subset: true });

subset: true is what keeps the cost near zero — only the handful of glyphs on the page get embedded, not the whole 300 KB face. We probe a small candidate list and take the first that exists on the box (DejaVu Sans on our Linux servers covers Latin + Cyrillic + Greek; Arial/Segoe locally). If none is found, we ship the image without a text layer rather than failing the capture — losing search is not losing the archive.

Step 5 — draw it invisibly, and don't let one glyph kill the archive

for (const b of boxes) {
  const y = imageH - b.y - b.h + b.h * 0.2;
  try {
    pdfPage.drawText(b.t, { x: b.x, y, size: b.fs, font, opacity: 0 });
    drawn++;
  } catch (e) {
    skipped++;   // a glyph even this font can't encode — skip the word, keep the PDF
  }
}

opacity: 0 is the whole point: the image is what you see, the text is what you search. And the per-word try/catch matters — a single exotic glyph should cost you one unsearchable word, not the entire multi-page document.

Did it actually work?

Measured on a Cyrillic page before/after:

626 of 626 visible words got coordinates and a text entry
file grew 7086 KB → 7147 KB — +0.9%
/ToUnicode is present in the output, so the text is genuinely searchable and copyable, not just present

That +0.9% buys you Ctrl+F, copy-paste, and a document a screen reader can actually read — on what is still, pixel for pixel, an exact image of the page.

We do this on every capture at Site2PDF — it archives a page (or a whole site) as a PDF/PNG/JPG, and the PDF comes out searchable by default. If you want the end-user version of this rather than the engineering one, we wrote up how to save a website as PDF.

Converting a JavaScript-Rendered Web Page to PDF

PetrDev — Sat, 01 Aug 2026 09:58:41 +0000

If you've ever tried to turn a modern web page into a PDF programmatically, you've probably hit the wall: the file comes out blank, half-empty, or frozen on a loading spinner. The page looks perfect in the browser, so what gives?

The answer is timing. Most PDF approaches grab the HTML before the JavaScript has rendered the content. On a server-rendered page that's fine — the markup is already there. On a React/Vue/Angular app, the server sends an near-empty shell and the browser builds the DOM afterward. Capture too early and you save the shell.

Here's how to do it properly.

Why the naive approaches fail

wkhtmltopdf is the classic Google answer. It's fast and it's been around forever, but it uses an ancient WebKit build with effectively no modern JavaScript support. For a static page it's fine. For anything client-rendered, it captures the empty state.

Browser window.print() / Ctrl+P works because it is a real browser — but it's manual, single-page, and impossible to automate cleanly at scale.

Hitting the raw HTML with an HTTP client (axios/fetch then pipe to a PDF lib) has the same fatal flaw as wkhtmltopdf: no JS execution, no rendered content.

What you actually need is a real browser engine that runs the page's JavaScript, waits for it to settle, and then prints. That's Puppeteer.

The Puppeteer approach

Puppeteer drives a headless Chromium. It executes the page exactly like a normal Chrome tab, so whatever renders on screen is what you capture.

const puppeteer = require('puppeteer');

async function pageToPdf(url, outPath) {
  const browser = await puppeteer.launch({
    args: ['--no-sandbox', '--disable-setuid-sandbox'], // needed in most containers
  });
  const page = await browser.newPage();

  await page.goto(url, { waitUntil: 'networkidle0', timeout: 60000 });

  await page.pdf({
    path: outPath,
    format: 'A4',
    printBackground: true, // otherwise CSS backgrounds/colors are dropped
    margin: { top: '20px', bottom: '20px', left: '16px', right: '16px' },
  });

  await browser.close();
}

pageToPdf('https://example.com', 'out.pdf');

Two options here matter more than they look:

waitUntil: 'networkidle0' tells Puppeteer to consider navigation finished only when there have been no network connections for 500ms. For most SPAs that's the signal the data has loaded and the DOM is built. (networkidle2 allows up to 2 connections — useful for pages with long-polling or analytics beacons that never fully go quiet.)
printBackground: true — forget this and every background color, gradient, and image disappears, because Chrome's print path strips them by default.

The gotchas that still bite you

Getting a non-blank PDF is step one. Getting a correct one is where the edges show up.

Lazy-loaded content

Images and sections that load on scroll won't be in the PDF, because Puppeteer never scrolled. Force them in by auto-scrolling before you print:

await page.evaluate(async () => {
  await new Promise((resolve) => {
    let y = 0;
    const step = 300;
    const timer = setInterval(() => {
      window.scrollBy(0, step);
      y += step;
      if (y >= document.body.scrollHeight) {
        clearInterval(timer);
        window.scrollTo(0, 0);
        resolve();
      }
    }, 100);
  });
});

Web fonts not loaded yet

Text renders in a fallback font because the web font hadn't finished loading at print time. Wait for it explicitly:

await page.evaluateHandle('document.fonts.ready');

Print CSS overriding your layout

If the site ships a @media print stylesheet, Chrome applies it. Sometimes that's what you want; sometimes it nukes the layout. Force screen rendering with:

await page.emulateMediaType('screen');

Fixed headers repeating or covering content

Sticky/fixed elements can duplicate on every PDF page or overlap the body. The reliable fix is to neutralize them before printing — set their position to static (or hide them) via page.addStyleTag().

When self-hosting Puppeteer isn't worth it

Puppeteer is the right tool when you need PDFs inside a pipeline you control. But it comes with a real operational tail: a headless Chromium is heavy (200MB+), it needs the right system libraries in your container, it leaks memory if you don't manage browser instances carefully, and it falls over under concurrency unless you pool pages and cap parallelism. For a side feature — "let users export this page" — that's a lot of infrastructure to babysit.

If you just need the output and not the plumbing, a hosted service does the same headless-render-then-capture under the hood without the ops burden. I run site2pdf.online for exactly this — it renders each page in real Chrome (so JS content comes through), and it can also follow a site's internal links to capture multiple pages in one pass, exporting to PDF, PNG, or ZIP. Handy when the alternative is standing up and maintaining your own Chromium fleet.

Rule of thumb: if PDF generation is core to your product, self-host Puppeteer and own it. If it's a convenience feature at the edge, offload it.

Wrapping up

The blank-PDF problem is almost always a timing problem: capture happens before JavaScript renders. Use a real browser engine, wait for the network (and fonts) to settle, scroll to trigger lazy content, and enable printBackground. Do that and dynamic pages convert cleanly.

The full, copy-pasteable version of this — plus the fixed-header and multi-page handling — is worth keeping in a snippet somewhere. You'll reach for it more often than you'd expect.

I shipped a website-to-PDF SaaS on WordPress — here's the stack

PetrDev — Tue, 05 May 2026 09:09:28 +0000

Last month I launched Site2PDF — converts any website to PDF, PNG, JPG or ZIP. Here's the entire tech stack, because the choices might be useful if you're building something similar.

What it does

Paste a URL → get a PDF of the whole page (or the whole site). Free plan gives 5 archives/month, all formats, cookie banner removal. Paid starts at $9/mo for 15 archives and 200 pages per site.

The stack

Frontend: a custom WordPress theme. Yes, WordPress. Hear me out.

Native user accounts, sessions, roles
Native admin panel for analytics and user management
Customizer for site branding
Gutenberg-free, just PHP templates + SCSS + vanilla JS

Rendering: Node.js + Puppeteer running on the same VPS, called from PHP via proc_open. A bash-like pattern:

$command = sprintf(
    '%s %s %s %s --options-file %s',
    escapeshellarg($node_path),
    escapeshellarg($script),
    escapeshellarg($url),
    escapeshellarg($output),
    escapeshellarg($options_json)
);
exec($command . ' 2>&1', $output, $code);

PHP passes options (cookie hide, selectors to expand, etc.) as a temp JSON file the Node script reads.

PDF assembly: pdf-lib for multi-page PDFs (each page becomes its own PDF page). DOMPDF for single-page fallback.

Image processing: sharp for PNG→JPG conversion. archiver for ZIP.

Billing: Paddle Billing (started with Stripe, had to migrate — Stripe doesn't support my country). Paddle handles tax, EU VAT, Canadian GST etc. — a huge win for a solo founder.

Auth: Google OAuth 2.0 without any plugin. A REST API endpoint redirects to Google, callback sets a one-time login token, cookie is set on the next regular page load. Why? Because iOS Safari blocks cookies set during REST API redirects (ITP).

Infra: Contabo VPS ($5/mo). Nginx, PHP-FPM, MariaDB. Chrome installed as google-chrome-stable, Puppeteer launches it with executablePath override.

Why WordPress (not Next.js or Rails)

The honest answer: I've shipped WP for 10 years. Familiar tools win. The theme is under 4000 lines of PHP, ~2000 lines of SCSS. I didn't need a full framework for ~5 pages and a wizard UI.

WordPress also gives me:

Zero-effort admin for users, plans, payment history
Free page hierarchy (/pdf-tools/full-page-screenshot/)
Built-in Yoast SEO and Site Icon features

The hot take: WordPress is a perfectly fine backend for a simple SaaS if you disable the bloat and write real code. Most of the "WordPress is slow" complaints come from bloated themes and 40 plugins.

Things that bit me

Puppeteer fullPage + fixed headers — writeup in my other post
Cookie banners blocking the screenshot — had to intercept requests to policy.cookiereports.com before page load
iOS Safari OAuth — first attempt set the auth cookie inside the callback redirect. Safari's ITP killed it. Had to use one-time tokens + set cookie on a regular page navigation.
iCloud Private Relay breaking CSRF state — used IP hash as the state key, which broke when Apple rotates IPs between redirects. Switched to state-as-key.
Paddle sandbox vs production — separate accounts, separate keys, separate price IDs. Wrote a helper that picks the right IDs based on WEBTOOLS_PADDLE_ENV constant.

The architecture in one diagram

Browser (vanilla JS)
  → AJAX → PHP (screenshot-tools.php)
          → proc_open → Node worker (Puppeteer)
          → writes PNG to /uploads/screenshot-temp/
          → PHP assembles PDF/ZIP if needed
          → returns base64 or job ID
  ← polls status / downloads blob

Full-site mode uses a different flow (background worker + status polling). Single-page mode is one synchronous AJAX call.

What's next

Real API (the pricing page still says "API — Soon")
Subscription cancel button in-app (currently "email us")
Blog with the 2-3 dev.to posts ported over for SEO

Try it

site2pdf.online. Free plan doesn't need signup. If you try it and something breaks, the Contact form works.

Happy to answer any questions about the stack in the comments.

Cleaning up web pages for screenshots — a practical Puppeteer guide

PetrDev — Wed, 29 Apr 2026 10:42:41 +0000

If you've ever taken a screenshot of a real-world webpage with Puppeteer, you've seen the ugly truth: cookie banners, sticky headers frozen at weird positions, collapsed FAQ accordions, and "Subscribe!" popups.

Here are four small Puppeteer helpers I use to get clean, presentable screenshots. Each is one function, drop-in ready.

1. Kill cookie banners

async function hideCookieBanners(page, customSelectors = []) {
    await page.evaluate((selectors) => {
        // Known cookie-banner elements
        ['CookieReportsPanel', 'CookieReportsOverlay', 'CookieReportsBannerAZ']
            .forEach(id => document.getElementById(id)?.remove());

        document.querySelectorAll('[class*="wscr"],[id*="CookieReport"]')
            .forEach(el => el.remove());

        // Reset body scroll locks the banner often sets
        document.body.style.overflow = '';
        document.documentElement.style.overflow = '';

        // User-defined selectors (if they know their site)
        selectors.forEach(sel => {
            try {
                document.querySelectorAll(sel).forEach(el => {
                    el.style.setProperty('display', 'none', 'important');
                });
            } catch {}
        });
    }, customSelectors);
}

2. Hide arbitrary elements

async function hideElements(page, selectors) {
    if (!selectors.length) return;
    await page.evaluate(sels => {
        sels.forEach(sel => {
            try {
                document.querySelectorAll(sel).forEach(el => {
                    el.style.setProperty('display', 'none', 'important');
                });
            } catch {}
        });
    }, selectors);
}

Example: hide chat widgets, "cookies" bars, floating "Get started" buttons:

await hideElements(page, [
    '#intercom-container',
    '.crisp-client',
    '[class*="newsletter-popup"]'
]);

3. Unfix sticky headers

Sticky headers repeat on every "screen" of a fullPage screenshot — ugly. Convert them to position: relative:

async function unfixSticky(page, selectors) {
    await page.evaluate(sels => {
        sels.forEach(sel => {
            try {
                document.querySelectorAll(sel).forEach(el => {
                    el.style.setProperty('position', 'relative', 'important');
                    ['top', 'bottom', 'left', 'right', 'z-index']
                        .forEach(p => el.style.setProperty(p, 'auto', 'important'));
                    el.style.setProperty('width', '100%', 'important');
                });
            } catch {}
        });
    }, selectors);
}

4. Expand FAQs / accordions

Most FAQs use classes like _active or attributes like open. Give the function a CSS selector + action + value:

async function expandAccordions(page, pairs) {
    if (!pairs.length) return;
    await page.evaluate(rules => {
        rules.forEach(({ selector, action, value }) => {
            try {
                document.querySelectorAll(selector).forEach(el => {
                    if (action === 'class') {
                        el.classList.add(value || '_active');
                        // Also unhide next sibling (common FAQ pattern)
                        const next = el.nextElementSibling;
                        if (next) {
                            next.style.display = 'block';
                            next.style.maxHeight = 'none';
                            next.removeAttribute('hidden');
                        }
                    } else if (action === 'attribute') {
                        const [name, val = ''] = value.split('=');
                        el.setAttribute(name, val);
                    } else if (action === 'style') {
                        value.split(';').forEach(rule => {
                            const [p, v] = rule.split(':');
                            if (p && v) {
                                el.style.setProperty(p.trim(), v.trim(), 'important');
                            }
                        });
                    }
                });
            } catch {}
        });
    }, pairs);

    // Wait for CSS transitions
    await new Promise(r => setTimeout(r, 400));
}

Example usage:

await expandAccordions(page, [
    { selector: '.faq__question', action: 'class', value: '_active' },
    { selector: 'details', action: 'attribute', value: 'open=true' },
    { selector: '.accordion-body', action: 'style', value: 'display: block' }
]);

Putting it together

await page.goto(url, { waitUntil: 'domcontentloaded' });
await hideCookieBanners(page);
await hideElements(page, ['.chat-widget']);
await unfixSticky(page, ['.sticky-nav']);
await expandAccordions(page, [{ selector: '.faq__q', action: 'class', value: '_open' }]);
await page.screenshot({ path: 'clean.png', fullPage: true });

Where I use this

All four helpers ship in production on Site2PDF — a website-to-PDF tool I'm building. Users paste a URL, tick what to hide/expand, and get a clean archive.

If you're doing any kind of web scraping or automated screenshots, grab these — they'll save you a weekend of CSS archaeology.

Why your fixed header disappears in Puppeteer fullPage screenshots (and how to fix it)

PetrDev — Thu, 23 Apr 2026 15:54:52 +0000

I spent two evenings debugging this. Sharing so you don't have to.

The problem

When you call page.screenshot({ fullPage: true }) on a site with a position: fixed header, one of three things usually happens:

The header renders in the middle of the page (not at the top)
The header area is blank at the top of the PDF/PNG
Only the first page shows the header — subsequent "pages" don't

You open the site in a real browser: looks perfect. You open it in Puppeteer's viewport mode: also fine. Only fullPage: true breaks it.

Why this happens

Puppeteer's fullPage: true uses Chrome DevTools Protocol's captureBeyondViewport. Under the hood, Chrome rasterizes the whole document beyond the viewport — but position: fixed elements are painted relative to the current viewport, not the document. So if your script scrolled to the bottom of the page before taking the screenshot, the fixed header is captured at the bottom.

There's also a second issue: many sites have scroll-behavior: smooth on html. When you call window.scrollTo(0, 0), the scroll is animated and doesn't complete instantly. If Puppeteer captures before the animation finishes, header ends up in a weird intermediate position.

The fix

Three things need to happen before the screenshot:

Kill smooth scrolling so scrollTo is instant
Reset any hide-on-scroll transforms that JS scroll handlers may have applied
Actually scroll to (0, 0) and wait a tick for paint

Here's the code I use in production:

async function prepareForScreenshot(page) {
    await page.evaluate(() => {
        // Disable smooth scrolling — make scrollTo instant
        const style = document.createElement('style');
        style.textContent = 'html { scroll-behavior: auto !important; }';
        document.head.appendChild(style);

        // Reset hide-on-scroll state on common header selectors
        const headers = document.querySelectorAll(
            'header, .header, [class*="header" i], nav[class*="header" i]'
        );
        headers.forEach(el => {
            const cs = window.getComputedStyle(el);
            if (cs.position === 'fixed' || cs.position === 'sticky') {
                el.style.setProperty('transform', 'none', 'important');
                el.style.setProperty('opacity', '1', 'important');
                el.style.setProperty('visibility', 'visible', 'important');
                if (cs.display === 'none') {
                    el.style.setProperty('display', 'flex', 'important');
                }
                // Remove common "hidden on scroll down" classes
                ['hidden', 'is-hidden', 'scroll-up', 'scroll-down', 'header--hidden']
                    .forEach(c => el.classList.remove(c));
            }
        });

        // Scroll to top — now instant
        window.scrollTo(0, 0);
    });

    // Give the browser one paint frame to settle
    await new Promise(r => setTimeout(r, 300));
}

Call it right before page.screenshot:

await prepareForScreenshot(page);
await page.screenshot({ path: 'out.png', fullPage: true });

When the simple fix isn't enough

If the site has a transparent header overlaid on a hero (common modern pattern), the above works great — the header just renders on top of the hero like in a browser.

If the site has a hide-on-scroll JS library that listens to scroll events after your reset, you may need to dispatch a synthetic scroll event to let it re-evaluate:

window.scrollTo(0, 0);
window.dispatchEvent(new Event('scroll'));

What I'm building

I'm working on Site2PDF — a tool that converts any website to PDF, PNG, JPG or ZIP. This exact fix is running in production there. If you want to try it, the free plan is 5 archives/month with all formats and advanced options (cookie banner removal, sticky header unfix, accordion expansion).

Feedback welcome!