DEV Community: Gerardo Barrera

The 4 Best Free Resume Builders in 2026 (Tested & Compared)

Gerardo Barrera — Mon, 06 Jul 2026 20:01:56 +0000

Search "free resume builder" and you'll get a wall of tools that all claim to be free. Then you spend an hour building a resume, hit Download, and — surprise — it's $2.95 for a "3-day trial" or your PDF comes out plastered with a watermark.

So I ran the test properly. For each tool I: created a resume from scratch, tried the templates, checked whether the output was ATS-friendly, and attempted to download a PDF without entering a credit card. Below are the four that were actually free, ranked by how little they made me fight for it.

How I tested

Same process for every tool, so the comparison is apples-to-apples:

Free PDF export — can you download without paying?
Watermark — is the free output clean?
Credit card — required to finish or not?
ATS-friendly — single-column, text-based, parseable output?
AI help — any writing/keyword assistance on the free tier?

Here's the summary, then the details.

Tool	Free PDF	Watermark	Credit card	ATS-friendly	Free AI
FlowCV	✅	❌ none	❌ no	✅	⚠️ limited
JobScoutly	✅	❌ none	❌ no	✅	✅
Canva	✅	❌ none	❌ no	⚠️ design-heavy	❌
Google Docs	✅	❌ none	❌ no	✅ (with a plain template)	❌

1. FlowCV — best free plan overall

FlowCV is the one I'd hand to a friend who just wants a clean resume with zero friction. Unlimited resumes, real PDF export, no watermark, no card. The templates are tasteful and default to single-column layouts that parse well.

Pros: Genuinely free core, clean ATS-friendly output, no account gymnastics.
Cons: Some newer designs and extras sit behind a paid tier; AI help is limited.

2. JobScoutly — best free AI + ATS matching

JobScoutly earns this spot because the AI writing help and resume-to-job-description matching are free with no premium tier, which is unusual. You paste a job description and it flags missing keywords and skills, and the templates are single-column and ATS-friendly by default.

Pros: All features free (AI writing, ATS templates, keyword matching, unlimited downloads), no watermark, no card.
Cons: Newer product with a smaller template library than the design-first tools; requires a free account to save your work.

3. Canva — best for creative roles

If you're a designer, a resume that looks like you can design is a feature. Canva's free tier exports clean PDFs with no watermark, and the template variety is unmatched.

Pros: Beautiful templates, free PDF export, great for portfolios and creative fields.
Cons: Most templates are multi-column and graphics-heavy — the opposite of ATS-friendly. Great for a human, risky for a parser. Use it only when you know a person reviews first, or pick one of the plain single-column templates.

4. Google Docs — best for full control

Not flashy, but honest: free forever, no watermark, and you control every pixel. Start from a plain template (skip the multi-column ones) and you get a text-based, parseable resume.

Pros: Totally free, reliable export, full control, nothing hidden.
Cons: No guidance, no AI, no ATS checks — you're on your own for content and formatting.

The "looks free but isn't" list

Worth naming, because these eat the most hours: several popular builders (you know the ones — the ones advertising everywhere) let you build the whole resume for free, then gate the download behind a subscription, sometimes via a cheap "trial" that auto-renews. That's not free; that's a funnel. If a tool won't let you export a clean PDF without a card, assume it's paid.

How to pick

Just want it done, clean, fast: FlowCV.
Want AI help + job-description matching for free: JobScoutly.
Creative field, human reviewer: Canva (single-column template).
Want total control, no accounts: Google Docs.

Whatever you choose, run the five-second test before you apply: copy-paste your exported PDF into a plain text file. If it comes out scrambled or missing sections, an ATS will choke on it too — pick a more parseable template regardless of which tool made it.

Which free builder have you actually shipped a resume from? Curious whether anyone's found one I missed that clears the "no card, no watermark" bar.

Why HTML-to-PDF Breaks in Production (and What to Use Instead)

Gerardo Barrera — Fri, 26 Jun 2026 02:55:12 +0000

Almost every "generate a PDF" feature starts the same way.

You already have HTML. You already have CSS. So you reach for the obvious move: render the page, screenshot it to PDF, ship it. Puppeteer, Playwright, wkhtmltopdf, a hosted "HTML to PDF API" — pick your flavor. In an afternoon you have an invoice coming out the other end and it looks fine.

Then it goes to production. And "fine" slowly turns into a backlog of weird, hard-to-reproduce bugs.

This is not an argument that HTML-to-PDF is useless. For a one-off export or an internal report, it's great. The argument is narrower: the moment PDF generation becomes a real, automated, customer-facing part of your product, "screenshot a web page" is the wrong abstraction — and the failure modes are predictable enough to list in advance.

The core problem: a PDF is not a web page

A browser renders for an infinite, scrollable, single-width viewport. A PDF is a stack of fixed, finite, printable pages.

Those are different physics.

HTML-to-PDF works by rendering your page in a headless browser and then slicing that continuous render into page-sized pieces. Everything that's hard about it comes from that one mismatch: you designed for a stream, and now you're forcing it into pages.

Most of the bugs below are just that mismatch showing up in different costumes.

Failure mode 1: pagination

This is the big one.

A browser has no concept of "page 2." So when your content is taller than one page, the engine has to guess where to cut — and it cuts wherever the pixel ruler lands.

That means:

a table row sliced in half across the page break
a heading stranded alone at the bottom of a page, its content on the next
a total row that floats away from the table it belongs to
a signature block split from the line above it

CSS has break-inside: avoid, break-before, and friends — and they help. But support is uneven across engines, they interact badly with flex/grid, and you end up hand-tuning rules per document until it looks right for the data you tested with. Which leads directly to the next problem.

Failure mode 2: it passes review, then real data breaks it

You test with "Acme Inc." and a two-line invoice. It's perfect. You ship.

Then production sends:

a customer name that's 90 characters long
a line-item description that wraps to three lines
an invoice with 47 items instead of 2
a localized currency string twice as wide as $
an address with a missing field, collapsing the layout

Now the logo overlaps the header. The table pushes the total onto a second page by itself. The footer rides up into the body. None of it reproduced locally, because the layout was implicitly tuned to your sample data, not to the full range of real data.

A layout that only holds for the data you happened to test with isn't a layout. It's a coincidence.

Failure mode 3: fonts and rendering drift

The PDF looked right on your machine. On the server it's Times New Roman, because the font you used isn't installed in the container.

Headless rendering inherits every environment-specific quirk of a real browser:

missing fonts silently fall back to something ugly
emoji and non-Latin scripts render as tofu boxes (□□□)
print media queries behave differently than what you previewed on screen
a Chrome version bump subtly shifts spacing, and last month's pixel-perfect invoice now wraps differently
high-resolution images blow up the file size or come out blurry depending on the device scale factor

You don't control the renderer. You control a configuration of a renderer that changes underneath you.

Failure mode 4: the operational tax

Even when the output is correct, running a browser to make a PDF is a heavy way to make a PDF.

Each render spins up a headless Chrome process. In production that means:

hundreds of MB of RAM per render, and CPU spikes under load
a process that can hang, leak, or zombie — so now you need timeouts, restarts, and a watchdog
slow cold starts that make this miserable in serverless/Lambda
a fat, fragile dependency (the whole browser) baked into your container
a brand-new scaling bottleneck: concurrent PDF requests now compete for browser processes

You set out to render a document and accidentally adopted a browser fleet to operate.

Failure mode 5: security surface

Headless browsers execute whatever they're told to render. The instant any user-controlled content reaches the template — a name, a note, a logo URL — you've opened the door to:

SSRF via <img>/<link>/@import pointing at internal services or cloud metadata endpoints
local file reads through file:// URLs
JavaScript execution and resource exfiltration unless you've carefully locked the sandbox down

It's all manageable. But "I just wanted an invoice" turned into running a content-injection-capable browser engine on your infrastructure, and that's a real surface you now own.

Why these keep happening

Step back and the pattern is obvious: every one of these bugs comes from making the layout engine re-derive the document on every render.

The browser doesn't know it's making an invoice. It knows it's painting a box model. So it re-flows, re-paginates, and re-decides everything, every time, from whatever HTML and data you handed it — and any of those decisions can go sideways when the inputs change or the environment shifts.

The data changes every render. The layout almost never does. But HTML-to-PDF couples them, so a change in data can corrupt the layout.

What to use instead: structured templates

The alternative is to stop screenshotting a web page and instead render from a structured template — a real document definition (pages, blocks, tables, text frames) that's built to paginate and reflow as a document, not as a viewport.

The split looks like this:

HTML-to-PDF:   data + layout-as-HTML  →  browser  →  screenshot  →  slice into pages
Structured:    data  →  reusable template  →  document renderer  →  PDF

Concretely, you separate the two things that were tangled together:

The template is designed once. It owns the layout: page size, margins, typography, where the logo goes, how the table behaves when it has 2 rows or 200.
The data is all that changes per render. You send JSON; the template absorbs it.

Because the renderer understands documents instead of viewports, the failure modes above stop being your problem:

Pagination is a first-class concept — tables break across pages with headers repeating, rows stay intact, totals stay attached.
Long/variable data reflows inside the structure instead of overflowing it — a 90-character name wraps, a 200-row table paginates, the layout holds.
Fonts are part of the template, embedded and deterministic — no server-environment roulette.
No browser means no per-render Chrome process, no cold-start tax, no browser CVEs to babysit.
No arbitrary HTML/JS execution, so the content-injection surface mostly evaporates.

Same template, every time. Same spacing, same fonts, same brand. Only the data is different.

What it looks like in practice

Instead of building an HTML string and handing it to a browser, you design the template once, then generate from data:

{
  "customer_name": "Acme Inc.",
  "invoice_number": "INV-1048",
  "due_date": "2026-07-24",
  "line_items": [
    { "description": "API usage",    "quantity": 1, "amount": "$480.00" },
    { "description": "Support plan",  "quantity": 1, "amount": "$199.00" }
  ],
  "total": "$679.00"
}

That's the entire per-render payload. No markup, no CSS, no print media queries, no break-inside incantations. Send the data, get back a finished PDF. Whether it's one document or ten thousand, the template already solved the layout — you're not re-solving it on every request.

This is the idea behind PDFMakerAPI: design a reusable PDF template in a visual editor, then generate PDFs from your data — by REST API, no-code workflows (Zapier/Make/n8n), or an AI agent over MCP. A PDF generation API for document automation, specifically so the layout stops being something every render has to rediscover.

When HTML-to-PDF is still the right call

To keep this honest: reach for headless Chrome when

it's a genuine one-off or low-volume internal export,
you're literally trying to archive a web page as it appears (that's the one case where "screenshot the page" is the actual requirement), or
the layout is throwaway and consistency doesn't matter.

The problems start when the document is reused, branded, automated, generated in bulk, or sent to customers — because that's when consistency, determinism, and operational cost stop being optional.

The takeaway

HTML-to-PDF feels free because you already have the HTML. The cost shows up later, in production, as pagination bugs, layout breakage on real data, font drift, a browser fleet to operate, and a security surface you didn't mean to adopt.

If you're exporting a web page, screenshot the web page.

If you're generating a document — the same document, over and over, with different data — design the template once and render from structured data. Let the data change. Keep the layout fixed.

That's the difference between a PDF feature that works in the demo and one that survives production.

Stop Letting AI Generate Your PDFs From Scratch

Gerardo Barrera — Thu, 25 Jun 2026 02:01:00 +0000

AI agents are getting weirdly good at doing work.

Ask Claude, ChatGPT, Cursor, or any coding agent to “make me an invoice PDF,” and it will usually try. It might write Python with ReportLab. It might generate HTML and CSS. It might spin up Playwright. It might patch a few layout bugs, retry the render, and eventually hand you a PDF.

At first, that feels magical.

Then you ask it to do the same thing again tomorrow.

And it rebuilds the whole thing from scratch.

Different spacing. Different column widths. Different font choices. Maybe the address block moved. Maybe the footer disappeared. Maybe it handled long line items differently this time.

That is not automation.

That is a very expensive intern redrawing your invoice every time you need one.

The problem is not AI-generated documents

The problem is using an LLM as a layout engine.

LLMs are great at:

understanding what kind of document you need
extracting the right fields
transforming messy input into clean structured data
deciding which template should be used
writing customer-specific language
filling missing-but-obvious values

They are bad at:

pixel-perfect layout
consistent spacing
deterministic rendering
pagination
table overflow
preserving brand rules
generating the exact same output every time

That matters because most business documents are not creative writing exercises.

Invoices, receipts, certificates, contracts, reports, order forms, proposals, and onboarding packets usually follow the same structure every time.

The data changes.

The layout does not.

So why are we asking the model to regenerate the layout on every request?

You are paying the model to re-solve a solved problem

Imagine this invoice data:

{
  "customer": "Acme Inc.",
  "invoice_number": "INV-1048",
  "due_date": "2026-07-24",
  "line_items": [
    { "description": "API usage", "quantity": 1, "amount": "$480.00" },
    { "description": "Support plan", "quantity": 1, "amount": "$199.00" }
  ],
  "total": "$679.00"
}

That data is tiny.

But when you ask an AI agent to generate the PDF from scratch, it does not just output that data. It generates layout code too.

It has to decide:

page size
margins
typography
table structure
column widths
header placement
footer placement
colors
spacing
overflow behavior
PDF rendering library
error handling

Then it has to run the code.

Then it has to fix the code.

Then it has to hope the next invoice still fits.

Now multiply that by 1,000 invoices.

You do not have one reusable document workflow.

You have 1,000 tiny code generation projects.

That is the hidden tax of AI-generated PDFs.

The output drifts because the model is doing too much

This is the part that makes AI document generation dangerous for real workflows.

A human sees this prompt:

Make an invoice for Acme Inc. with these line items.

An LLM sees an open-ended generation task.

It might produce a good invoice. But unless you force the layout into a deterministic system, the model has room to improvise.

And improvisation is exactly what you do not want in business documents.

You do not want invoice #1048 to use a slightly different layout than invoice #1049.

You do not want your certificate title centered one day and slightly off-center the next.

You do not want a contract clause to wrap differently because the model changed the font size.

You do not want a customer report to break because one field was longer than expected.

For one-off documents, this is fine.

For automated document generation, it is a bug.

The better pattern: separate layout from data

The fix is boring.

That is why it works.

Design the document once.

Then generate it forever with data.

Instead of asking the LLM to generate the entire PDF every time, give it a much smaller job:

Understand the request and produce structured JSON.

Then let a deterministic renderer handle the layout.

The workflow becomes:

User request
   ↓
AI agent extracts structured data
   ↓
Reusable PDF template receives data
   ↓
PDF renderer generates consistent output

The LLM is still useful.

It is just not pretending to be a PDF layout engine anymore.

What this looks like in practice

Instead of asking an agent:

Create an invoice PDF from scratch.

Ask it:

Use the invoice template and fill it with this customer data.

The model should only need to produce something like this:

{
  "template_id": "invoice",
  "data": {
    "customer_name": "Acme Inc.",
    "invoice_number": "INV-1048",
    "due_date": "2026-07-24",
    "line_items": [
      {
        "description": "API usage",
        "quantity": 1,
        "amount": "$480.00"
      },
      {
        "description": "Support plan",
        "quantity": 1,
        "amount": "$199.00"
      }
    ],
    "total": "$679.00"
  }
}

That is the right job for an LLM.

Small output.

Structured data.

Easy to validate.

Cheap to retry.

No layout drift.

No surprise CSS.

No headless browser roulette.

This is why I built PDFMakerAPI

PDFMakerAPI is built around this exact idea:

Design the PDF template once. Generate finished PDFs by sending data.

You can create reusable templates visually, then fill them through an API, no-code workflows, or AI agents.

The important part is that the template is reusable.

The AI does not need to redraw the invoice.

It does not need to re-invent the table.

It does not need to decide where the logo goes.

It just sends data.

The layout engine does the boring deterministic work.

That is how document automation should work.

Using it from an AI agent with MCP

With MCP, an agent like Claude, Cursor, or ChatGPT can call a document generation tool instead of writing PDF code.

The agent receives a request like:

Make an invoice for Acme Inc. for API usage and support, due net 30.

Instead of generating layout code, the agent calls a tool with structured data.

Conceptually:

{
  "template_id": "invoice",
  "data": {
    "customer_name": "Acme Inc.",
    "payment_terms": "Net 30",
    "line_items": [
      {
        "description": "API usage",
        "quantity": 1,
        "amount": "$480.00"
      },
      {
        "description": "Support plan",
        "quantity": 1,
        "amount": "$199.00"
      }
    ],
    "total": "$679.00"
  }
}

The result is a finished PDF using the same template every time.

Same spacing.

Same fonts.

Same table.

Same brand.

Different data.

That is the entire point.

Using it from an API

The same pattern works without an agent.

Your app sends JSON:

curl https://api.pdfmakerapi.com/v1/render \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "template_id": "invoice",
    "data": {
      "customer_name": "Acme Inc.",
      "invoice_number": "INV-1048",
      "total": "$679.00"
    }
  }' \
  --output invoice.pdf

Now your document generation is just part of your application.

No prompt loops.

No generated layout code.

No “let me fix this PDF script” step.

No inconsistent output.

Bulk generation should not mean bulk prompting

This is where the difference becomes obvious.

Bad pattern:

Prompt the AI 1,000 times.
Generate 1,000 different pieces of layout code.
Render 1,000 PDFs.
Hope they match.

Better pattern:

for invoice in invoices:
    response = requests.post(
        "https://api.pdfmakerapi.com/v1/render",
        headers=headers,
        json={
            "template_id": "invoice",
            "data": invoice
        }
    )

    with open(f"{invoice['invoice_number']}.pdf", "wb") as f:
        f.write(response.content)

That is real automation.

The template is already designed.

The layout is already solved.

The only thing changing is the data.

When AI-generated PDFs are still fine

To be fair, there are cases where generating a PDF from scratch is totally reasonable.

If you need a quick one-off mockup, a temporary chart, or a throwaway internal document, let the model improvise.

That is fine.

The problem starts when the document matters.

If it needs to be reused, branded, audited, emailed to customers, generated in bulk, or produced consistently, then “AI, please make me a PDF” is the wrong abstraction.

The better abstraction is:

AI, understand the request and fill the right template.

The future is not AI drawing boxes forever

AI agents should not be spending tokens deciding where an invoice table goes.

They should not be writing and rewriting PDF layout code for documents your company already standardized months ago.

They should understand intent, prepare data, call tools, and let deterministic systems do deterministic work.

That is the pattern that scales.

Use AI for the messy human part.

Use templates for the boring layout part.

Design once.

Generate forever.

You can try the workflow with PDFMakerAPI — reusable PDF templates, visual editing, API generation, and MCP support for AI agents.

The next time an AI agent starts writing 200 lines of PDF layout code, ask yourself:

Did I need a smarter model, or did I just need a reusable template?

Generate PDFs from JSON in Any Language — One REST API (Python, Node, PHP, Go)

Gerardo Barrera — Wed, 24 Jun 2026 05:10:18 +0000

Every backend eventually has to spit out a PDF — an invoice, a receipt, a report, a certificate. And in every language, the options are bad:

Headless Chrome / Puppeteer — you render HTML to PDF. Works until your data gets long: tables split across pages, fonts go missing, and you're babysitting a browser farm in production.
Native libraries (ReportLab in Python, PDFKit in Node, FPDF in PHP, gofpdf in Go) — you position everything by hand in code. Generic fonts, fragile layouts, and the design lives in your codebase forever.

There's a cleaner separation: design the document once, then feed it data over HTTP. Because it's just a REST call, the exact same approach works in any language.

The idea: template + data → PDF

Design a reusable template once — visually, or by describing it to an AI — with placeholders like {{customer}} and {{total}}.
POST your JSON to one endpoint with the template ID.
Get back a finished, editable PDF.

No HTML/CSS, no headless browser, no fonts to ship. Here's the same request in five languages.

curl

curl https://api.pdfmakerapi.com/v1/render \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "template_id": "invoice_default",
        "data": { "number": "INV-1042", "customer": "Acme Inc.", "total": 49.00 } }' \
  --output invoice.pdf

Node.js

const res = await fetch("https://api.pdfmakerapi.com/v1/render", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.PDF_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    template_id: "invoice_default",
    data: { number: "INV-1042", customer: "Acme Inc.", total: 49.0 },
  }),
});
require("fs").writeFileSync("invoice.pdf", Buffer.from(await res.arrayBuffer()));

Python

import os, requests

res = requests.post(
    "https://api.pdfmakerapi.com/v1/render",
    headers={"Authorization": f"Bearer {os.environ['PDF_API_KEY']}"},
    json={
        "template_id": "invoice_default",
        "data": {"number": "INV-1042", "customer": "Acme Inc.", "total": 49.00},
    },
)
open("invoice.pdf", "wb").write(res.content)

PHP

<?php
$res = file_get_contents("https://api.pdfmakerapi.com/v1/render", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer {$_ENV['PDF_API_KEY']}\r\nContent-Type: application/json",
    "content" => json_encode([
      "template_id" => "invoice_default",
      "data" => ["number" => "INV-1042", "customer" => "Acme Inc.", "total" => 49.00],
    ]),
  ],
]));
file_put_contents("invoice.pdf", $res);

Go

body, _ := json.Marshal(map[string]any{
    "template_id": "invoice_default",
    "data":        map[string]any{"number": "INV-1042", "customer": "Acme Inc.", "total": 49.00},
})
req, _ := http.NewRequest("POST", "https://api.pdfmakerapi.com/v1/render", bytes.NewReader(body))
req.Header.Set("Authorization", "Bearer "+os.Getenv("PDF_API_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)
defer res.Body.Close()
out, _ := os.Create("invoice.pdf")
io.Copy(out, res.Body)

Same JSON, same endpoint, five languages. The PDF comes back in the response body.

Where the template comes from

You don't write HTML. You design the template in a visual, drag-and-drop editor — drop in text, tables, images, and {{variables}} — or describe it in plain English and let the AI build it. Change the design later without touching your code; your request body stays the same.

And because it renders from a structured template (not a screenshot of a webpage), layouts don't break when the data changes — and there's no headless browser, so it generates thousands of PDFs in seconds.

Generating in bulk

It's just HTTP, so loop your data:

for inv in invoices:
    pdf = requests.post(URL, headers=H, json={
        "template_id": "invoice_default", "data": inv,
    }).content
    open(f"{inv['number']}.pdf", "wb").write(pdf)

Try it

PDFMakerAPI is free to start — 100 PDFs/month, no card. Design a template, grab an API key, and you're rendering PDFs from any language in a few minutes. You can also generate from no-code tools (Zapier, Make, n8n) or straight from AI agents (Claude, ChatGPT) — same templates, same output.

What's the worst PDF-generation setup you've had to maintain? Curious what people are running.

How to Let an AI Agent Generate Real PDFs (with an MCP server)

Gerardo Barrera — Sat, 20 Jun 2026 04:37:27 +0000

AI agents are great at producing text. But the moment you need an actual document — an invoice, a report, a certificate — they fall apart. You get markdown you have to format yourself, or (with Code Interpreter) a rough PDF from a Python lib with generic fonts and tables that never quite look right. There's no clean way to hand an agent the job of "produce a polished PDF."

So I gave my agents one tool that does exactly that, over MCP (Model Context Protocol). The agent describes the document, and gets back a link to a finished, editable PDF. Here's how to wire it up in about 5 lines of config.

Disclosure: I work on PDFMakerAPI — but the pattern here (give an agent a single, well-scoped tool that returns a reviewable artifact) applies to any MCP server. The config below just happens to use mine.

30-second MCP refresher

MCP is the open standard for giving an AI agent tools. You point your client (Claude Desktop, Cursor, Windsurf, Cline, VS Code, ChatGPT…) at an MCP server, and the agent can now call whatever functions that server exposes. No glue code, no custom integration per client — that's the whole appeal.

The server we're adding exposes exactly one tool: create_document. (One tool on purpose — a small, predictable surface area is easier for an agent to use correctly than a grab-bag of twenty.)

Step 1 — Add the server

Drop this into your client's MCP config (Claude Desktop: Settings → Developer → Edit Config; Cursor: ~/.cursor/mcp.json; same idea elsewhere):

{
  "mcpServers": {
    "pdfmakerapi": {
      "command": "npx",
      "args": ["-y", "@pdfmakerapi/mcp"]
    }
  }
}

Restart the client. That's the entire setup — no API key, no account.

Using a web client like Claude.ai or ChatGPT that can't run npx? Add the hosted endpoint as a custom connector instead:

https://api.pdfmakerapi.com/mcp

Step 2 — Ask for a document

Now just ask the agent in plain English:

"Make a professional invoice for Acme Corp — 3 line items, net 30."

The agent calls create_document, and you get back a link like:

https://app.pdfmakerapi.com/d/019ee2fe-c503-71c0-aaf6-68cf33ca096c

Open it and you'll see the finished invoice — and you can edit any field before downloading the PDF. Here's a real one to click:
👉 Live invoice example

It works for invoices, receipts, certificates, reports, resumes, letters — if the agent can describe it, it can lay it out with headings, tables, and your data.

Why the "editable link" matters for agents

This is the part I actually care about, and it's why I didn't make the tool just spit out a final PDF.

If you've spent any time running agents in production, you know the failure mode isn't "bad answer" — it's a wrong action that's already done. An agent that emails the wrong customer or files the wrong number is worse than one that just says something dumb.

Returning an editable document instead of a finalized file builds a natural human-in-the-loop checkpoint into the workflow:

The agent drafts the document from the request.
A human opens the link, checks it, fixes anything, and downloads.

So the agent does the tedious 90% (layout, structure, pulling the data together), but a person stays in control of what actually ships. For anything that leaves the building — an invoice to a client, a certificate with someone's name on it — that checkpoint is worth a lot more than full autonomy.

What it does not do (so you scope it right)

Being straight about the edges:

It generates documents — it does not read or edit a PDF you upload. Different problem.
It returns an editable web document + a downloadable PDF, not a blank fillable form to hand out.

If your agent needs to produce structured documents from data or a prompt, this fits. If it needs to parse existing PDFs, you want a different tool.

Under the hood (for the curious)

create_document takes a document model — a small JSON tree of nodes (text, containers, tables) with optional {{variables}} — and stores it, returning the share link. The agent can build that structure from a prompt, or you can POST it yourself to the same REST API if you'd rather skip the agent entirely. It's open source (MIT) if you want to read the tool definition: github.com/GerardoBarrera/pdfmakerapi-mcp.

Wrap-up

Giving an agent the ability to produce a real, reviewable document turned out to be a small change with a big payoff:

Add one MCP server (~5 lines).
Ask for the document in plain English.
Get an editable link a human can sign off on before it ships.

No markdown-to-PDF wrangling, no headless browser, and a built-in review step instead of blind autonomy.

If you're building agents that produce deliverables (not just text): do you let the agent finalize, or always hand off to a human to review first? Genuinely curious how others are drawing that line — drop it in the comments.

How to Generate a PDF from JSON in Node.js (without a headless browser)

Gerardo Barrera — Sat, 20 Jun 2026 04:29:56 +0000

If you've ever had to generate PDFs from a Node app — invoices, receipts, reports, certificates — you've probably reached for
Puppeteer or some headless-Chrome setup. It works… until you have to run it in production. Now you're shipping a 300MB Chromium
binary, babysitting a browser process, fighting memory leaks, and your "render a PDF" endpoint times out under load.

There's a simpler way: describe the document as JSON, POST it to an API, get a PDF back. No browser. In this post I'll show how
to go from a JSON payload to a finished, editable PDF in about 15 lines of Node.

Full disclosure: I built PDFMakerAPI, the tool I'm using here. There's a free tier, no API key needed to
try it, and the code below runs as-is.

## The idea: separate the data from the design

The trick to sane PDF generation is to stop gluing strings of HTML together. Instead you keep two things separate:

The design — a layout of text, tables, and containers (you can design this visually, or describe it as JSON).
The data — the actual values that change per document.

You merge them with one request and get back a link to the finished PDF. Let's do it.

## Step 1 — Describe the document as JSON

A document is just a tree of nodes. Here's a minimal one — a short welcome letter with a {{customer_name}} placeholder:

  const document = {
    name: "Welcome Letter",
    pageSize: "letter",
    variables: [
      {
        id: "var_name",
        name: "customer_name",
        type: "text",
        label: "Customer Name",
        defaultValue: "Alex Morgan",
      },
    ],
    children: [
      {
        id: "title",
        name: "Title",
        type: "text",
        order: 1,
        width: "full",
        content: "Welcome aboard 🎉",
        fontSize: "xl",
        fontWeight: "bold",
        style: { textColor: "#111827" },
      },
      {
        id: "body",
        name: "Body",
        type: "text",
        order: 2,
        width: "full",
        content:
          "Hi {{customer_name}}, thanks for joining. This whole PDF was generated from JSON in a single API call — no headless browser
  involved.",
        fontSize: "md",
        style: { textColor: "#374151" },
      },
    ],
  };

Anything in {{double_braces}} is a variable, so you can reuse the same layout with different data. The full schema (containers,
tables, images, fonts, page settings) is in the docs and repo — but the shape
above is all you need to start.

## Step 2 — POST it and get a link back

  const res = await fetch("https://api.pdfmakerapi.com/api/v1/documents", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ document }),
  });

  const { id, url } = await res.json();
  console.log(url);
  // → https://app.pdfmakerapi.com/d/<id>

That's it. The response is { id, url }, where url opens the finished document.

Prefer curl?

  curl -X POST https://api.pdfmakerapi.com/api/v1/documents \
    -H "Content-Type: application/json" \
    -d '{ "document": { "name": "Welcome Letter", "pageSize": "letter", "children": [ { "id": "t", "type": "text", "order": 1, "width":
  "full", "content": "Generated from JSON ✅", "fontSize": "xl", "fontWeight": "bold" } ] } }'

## Step 3 — The part Puppeteer can't do: an editable result

Here's the difference that matters. The link you get back isn't a flat, one-shot render — it opens an editable document. You (or
anyone you send the link to) can change any field in the browser and the preview updates live, then download the PDF.

Here's a real one generated this way — open it and edit a field:
👉 Live invoice example

That turns out to be a big deal in practice: your app drafts the document, but a human can review and fix it before it goes out —
instead of trusting whatever got rendered.

## Bonus: you don't even have to write the JSON

If hand-building the node tree feels tedious, you can skip it entirely. PDFMakerAPI ships an MCP server, so an AI agent (Claude,
Cursor, ChatGPT, etc.) can generate the document structure from a plain-English prompt:

  {
    "mcpServers": {
      "pdfmakerapi": { "command": "npx", "args": ["-y", "@pdfmakerapi/mcp"] }
    }
  }

Then just ask: "make an invoice for Acme with 3 line items" and it returns the same kind of editable link. Same engine, no JSON by
hand.

## When you should NOT use this

Being honest: an API isn't always the right call.

If you need to screenshot an existing web page to PDF, a headless browser is the right tool — that's literally what it's for.
If you're generating one PDF, once, locally, a library like pdfkit is fine.

Where this approach wins is generating structured documents from data, repeatedly, in production — invoices, receipts, reports,
certificates — without running a browser farm.

## Wrap-up

To generate a PDF from JSON in Node:

Describe the document (or let an AI agent describe it).
POST it to /api/v1/documents.
Get back a link to an editable, downloadable PDF.

No Chromium, no rendering servers, no timeouts. If you want to try it, the free tier gives you 100 PDFs/month with no card, and the MCP server is open source (MIT) on GitHub.

If you're generating PDFs in production today — what are you using, and what's been the most painful part? Curious to hear in the
comments.