DEV Community: Collin Mendons

How to generate a PDF report automatically (and the step everyone skips)

Collin Mendons — Fri, 26 Jun 2026 13:20:11 +0000

Answer block

To generate a PDF report automatically you wire up three pieces: a data source, a template that defines the layout, and an engine that merges them on a trigger or schedule. You can do it in code (Python libraries like ReportLab or FPDF) or with no-code template APIs (CraftMyPDF, Adobe Document Generation) connected to an automation platform like Zapier, Make, or n8n.

My first automated PDF report started life as a five-minute job. Marketing wanted the same weekly summary every Monday, a few tables and a chart, exported clean so it could go straight into a deck. Easy. I'd done harder things before lunch.

The rendering part took an afternoon, like I expected. The data part took two weeks. And that gap, between the part that looks like the work and the part that actually is the work, is the thing almost every "how to generate a PDF report" tutorial gets backwards.

So here's the honest version. The methods that work, when to reach for each, and the step that quietly eats most of the time.

What generating a PDF report actually involves

Three pieces have to come together. A data source that holds the numbers. A template that says where everything goes and how it looks. And a merge engine that pours one into the other and spits out a file.

Most guides spend all their words on the third piece, because that's where the satisfying code lives. You call a function, a PDF appears, it feels like magic. The first two pieces are where the real work hides, and we'll get to why.

For now, the merge engine. There are two honest ways to build it.

Option 1: do it in code

If you're already comfortable in a scripting language, generating the PDF yourself gives you the most control and costs nothing but your time.

In Python, ReportLab is the heavyweight: full control over layout, fonts, tables, vector charts, the works. FPDF is the lighter option when you just need text and simple tables on a page. Pair either with pandas to shape the data and matplotlib to render charts as images you drop in, and you can produce something genuinely polished.

If you want a concrete starting point, there's a solid walkthrough of the whole pattern in this Towards Data Science guide.

The trade-off is maintenance. Every layout tweak is a code change, and "can we move the logo and add the regional breakdown" turns into a small ticket instead of a two-minute edit. Code is the right call when the report is stable, the volume is high, and you want it running on a server with nobody touching it.

Option 2: a template plus an automation platform

If you're not writing code, or you don't want the layout living inside a script, the cleaner path is a template API wired to an automation tool.

The shape is simple. You design the report once in a visual editor, leaving placeholders for the values. A service like CraftMyPDF or Adobe's Document Generation API takes your template plus a chunk of JSON and returns a pixel-perfect PDF.

Then you let an automation platform do the triggering. A new row lands in Airtable or Google Sheets, Zapier or Make or n8n grabs that row, sends it to the template service, and emails the finished report wherever it needs to go.

The win here is that the design lives somewhere a non-developer can change it. When marketing wants the logo moved, they move it, and nobody opens a code editor. The cost is a monthly bill and a ceiling on how weird your layouts can get before the template editor fights you.

For most teams that aren't engineering-heavy, this is the route I'd point you at first.

The step every tutorial skips

Here's what both options quietly assume: that your data already sits in a clean table somewhere, ready to be merged.

Mine didn't. Half the numbers for that Monday report lived in places with no export button. A vendor dashboard that showed the figure on screen and offered no download. A supplier portal behind a login. A partner's analytics page that updated whenever they felt like it. Every week, before any template or script could run, somebody had to open six tabs and copy values into the spreadsheet by hand. That copying was the two weeks. The PDF generation was the afternoon.

This is the part worth saying out loud, because it changes what you should automate first. If the data already flows into a database or a sheet through an API, pick either option above and you're done. If it doesn't, the report generator isn't your bottleneck. The gathering is. And gathering data off websites that were never built to share it is its own problem, separate from rendering a file.

The tools that handle that last part are browser agents that read a page the way a person does, rather than relying on an API that doesn't exist. I work on one called an AI browser agent, so take the mention with the appropriate grain of salt, but the category matters here whichever tool you reach for: it's what turns "someone copies these numbers every Monday" into a step that runs on its own.

If you want the longer version of why pulling data off a live site is a different problem from a normal export, I wrote up the line between scraping and driving a browser separately. The short of it is that one reads a feed and the other reads the screen.

How to pick, fast

You can code, the report is stable, volume is high → a Python library like ReportLab.
You want non-developers to own the layout → a template API plus Zapier, Make, or n8n.
Your data already lives in a sheet or database → either of the above, you're set.
Your data is trapped on dashboards or portals with no export → fix the gathering step first, then generate the PDF.

The mistake I made, and the one I see most often, is treating the whole thing as a rendering problem. You spend your effort making a beautiful generator and still hand-feed it data forever. Sort out where the numbers come from before you fall in love with the template, and the weekly report stops being a weekly chore.

FAQ

What's the easiest way to generate a PDF report from data?
For non-developers, a template service like CraftMyPDF or Adobe Document Generation connected to Zapier, Make, or n8n is the easiest. You design the layout once, and the automation fills it from a spreadsheet or database whenever new data arrives.

How do I generate a PDF report in Python?
Use ReportLab for full control over layout and charts, or FPDF for simpler text-and-table reports. Shape your data with pandas first, render any charts as images, then place everything into the document and save it. You can run the script on a schedule with cron or a CI job.

Can I automate PDF report generation without code?
Yes. Pair a no-code PDF template API with an automation platform. The platform watches a data source (like Airtable or Google Sheets), sends each new record to the template, and delivers the finished PDF by email or to storage, all without writing code.

Why does my automated report still need manual work every week?
Usually because the data lives somewhere without an export, like a dashboard or a login-gated portal, so a human copies it into the spreadsheet before the report can run. Automating that data-gathering step, not the PDF rendering, is what removes the recurring manual work.

Selenium vs Playwright in 2026 (and when the question is wrong)

Collin Mendons — Sun, 21 Jun 2026 18:12:44 +0000

Answer block

For most new browser automation projects in 2026, Playwright is the better default: it's faster, more reliable thanks to built-in auto-waiting, and has a smoother debugging experience than Selenium. Selenium is still the right pick when you need wider browser coverage (Edge legacy, older Safari), broader language bindings (Ruby, Kotlin), or you're maintaining an existing Selenium suite that would be expensive to migrate. If you're not a developer and just need to automate web work, neither is the right answer; an AI browser agent that reads the page and decides what to do is a better fit for that case.

I've shipped browser automation on both. Years of Selenium at a previous job, then Playwright once it stopped being the new kid and started being the default. From inside the IDE the two read totally different.

So when somebody asks me which one to pick in 2026, I have an answer. I also have a second answer, for the half of people asking the question who probably shouldn't be reaching for either.

I'll give you the first answer up front. Then we'll talk about the other one.

The short verdict for developers

If you're starting a new browser automation project today, default to Playwright. The architecture is better, the auto-waiting saves you from most of the flaky-test nightmares Selenium people complain about, and the debugging tools are years ahead. Unless one of these is true for you:

You need to support browsers Playwright doesn't (older Edge, weird embedded WebViews).
Your team writes in Ruby or Kotlin and you don't want to switch.
You already have 1,000+ Selenium tests and the migration cost is brutal.

If none of those apply, Playwright. Move on.

That's the verdict. Now the why.

Architecture: WebDriver vs talking to the browser directly

Selenium talks to the browser through WebDriver, which is a separate process the test runner sends HTTP requests to. Every action goes: test code, then WebDriver, then browser. That extra hop has been the source of basically every weird Selenium problem I've ever had. The driver gets out of sync. The driver crashes. The driver version doesn't match Chrome. You spend a Friday afternoon updating drivers.

Playwright cuts the hop. It speaks the Chrome DevTools Protocol directly (and the equivalents for Firefox and WebKit). The test runner is in the same process as the controller. Fewer moving parts. Fewer ways to break.

Doesn't sound like much on paper. In practice it's the difference between a green CI run and an angry Slack message at 2am.

Performance

Playwright is faster. Most honest benchmarks put it at roughly 2x Selenium on equivalent test suites. The biggest contributors are auto-wait (you stop sleeping unnecessarily) and the reduced HTTP round-trips from the architecture above.

How much that matters depends on your suite. If you have 50 tests and they finish in 4 minutes, you don't care. If you have 5,000 tests and CI is the bottleneck of your release process, it adds up to hours. I've seen teams cut their CI budget in half by migrating.

I wouldn't migrate just for the speed. I would migrate for the speed plus the reliability.

Reliability and auto-waits

This is the one that actually changes day-to-day life on the team. In Selenium, you write driver.find_element(...) and the element might not be there yet, so you sprinkle WebDriverWait calls everywhere. New people on the team forget. The tests pass locally and fail on CI. You spend Tuesday investigating a flake that turns out to be a timing issue on a button that animates in.

Playwright auto-waits. When you say page.click("button#submit"), it waits for the element to exist, be visible, be enabled, and be stable. If it isn't, you get a clear timeout with a screenshot. No more sleep(2) showing up in code reviews.

There's a fair counterpoint. A 2025 reliability study ran both for 24 hours and found Selenium hit 100% uptime while Playwright hit 99.72%. So Playwright isn't bulletproof, especially for very long-lived sessions. For a normal test suite, the auto-wait win still dwarfs that. For a 24/7 production scraper, weigh the number.

Browser and language support

This is where Selenium's age becomes an asset.

Selenium has official drivers for Chrome, Firefox, Safari, Edge (including legacy IE-mode in some cases), and basically anything else with a WebDriver implementation. Playwright supports Chromium, Firefox, and WebKit out of the box. WebKit isn't Safari (it's the engine behind Safari), so if you have to verify exact Safari behavior on macOS or iOS, Selenium has a real edge.

Language bindings are the same story. Selenium has official support for Java, C#, Python, Ruby, JavaScript, and Kotlin. Playwright officially supports JS/TS, Python, .NET, and Java. The Java and Python paths are solid on both. The Ruby and Kotlin teams have to either stay on Selenium or rely on unofficial bindings.

For most teams in 2026 this won't matter. For some teams it's the only thing that matters.

Debugging and developer experience

Debugging is where Selenium gets quietly beaten. Playwright ships with:

A trace viewer that records every action with before/after DOM snapshots.
A codegen tool that records your manual clicks into Playwright code.
An inspector that pauses execution and lets you step through.

Selenium has none of this natively. There are third-party tools, but they're not the default and they don't compose as cleanly.

The first time I caught a failing test in five minutes using Playwright's trace viewer, instead of the usual half-hour of console.log archaeology, I stopped pretending the comparison was close.

Now the second answer

Both tools are powerful and both are aimed at the same person: a developer who is comfortable writing selectors and maintaining a test suite. That's a fine target. It's not the only person reaching for this comparison.

Half the time someone asks me "should I use Selenium or Playwright," what they actually want is to automate something on the web (lead research, or repetitive form filling) and they aren't a developer. They Googled it, the comparison posts came back, and now they're stuck deciding between two things they can't really use.

For that person, the answer is neither.

The thing that's changed in the last two years is that AI browser agents can read a live page the way a person would, decide what to click, and do the job without selectors. No XPath, no CSS, no waiting strategy, no driver version drift. You describe the goal in plain English and the agent works the page. We built Browzey for exactly this audience: the operator or founder who needs the outcome and doesn't want to maintain test code to get it.

When the site changes, selector-based approaches break and the agent usually doesn't, because it's reading semantic meaning instead of brittle CSS paths. That's the part the Selenium-vs-Playwright debate doesn't really capture. Both tools live in the same selector-driven world.

If you're an engineer building a test suite for a product, Selenium vs Playwright is still your decision, and Playwright is usually the answer. If you're a founder trying to scrape leads off a directory or fill out the same web form 200 times, you're using the wrong family of tools. There's a whole different category of automation for you, and it doesn't start with "pip install selenium."

The cheat sheet

New project, you can pick freely → Playwright.
Heavy existing Selenium investment → stay, migrate slowly if at all.
Need Safari-on-actual-Safari or Ruby/Kotlin → Selenium.
You're a developer building tests → Playwright by default, Selenium for legacy reach.
You're not a developer, you want the outcome → AI browser agent.

The mistake I see most often: someone reads a comparison post, picks the "winner," writes a hundred tests, then the app gets a redesign and half the tests break overnight. The selector-based approach is fundamentally fragile to UI change. You can mitigate it. You can't make it go away.

Pick the layer that matches what you're actually trying to do. Test code is a fine layer for a product team. It's the wrong layer for a Tuesday afternoon scrape.

FAQ

Is Playwright better than Selenium in 2026?
For most new projects, yes. Playwright is faster, more reliable thanks to auto-waiting, and has a much better debugging story. Selenium is still better when you need to support legacy browsers (older Edge, IE-mode) or write tests in Ruby or Kotlin.

Can I use both Selenium and Playwright in the same project?
Yes, but you usually shouldn't. Each tool has its own driver, syntax, and waiting model. Mixing them inside one suite makes the codebase harder to maintain. The exception is a slow migration: keep Selenium for the legacy suite and write all new tests in Playwright until the old tests are gone.

Is Playwright easier to learn than Selenium?
Most developers say yes. Playwright's auto-waiting removes a class of timing bugs Selenium beginners hit constantly, and the codegen tool lets you record clicks into starter code. Selenium has more tutorials online (because it's older), so the raw volume of learning material is higher.

Which one is better for web scraping?
Playwright handles modern JavaScript-heavy sites better thanks to direct CDP access and built-in network interception. Selenium can scrape too, but the auto-wait absence makes it more prone to silent failures when content loads asynchronously. For a one-off scrape where you don't want to write code, neither tool is the right pick; an AI browser agent or a no-code scraper is faster.

Does Selenium have a future?
Yes. The Selenium project is still actively developed, browser-vendor support isn't going away, and millions of existing tests rely on it. New project momentum has shifted to Playwright, but Selenium isn't disappearing for a long time.