From Figma to PDF: the missing piece

Every PDF template in production starts its life in Figma. A designer sketches an invoice. It goes to the developer. The developer squints at it and writes <Heading>, <Text>, <Stack> components until it mostly looks right.

Two weeks later the designer updates the Figma. The developer translates again. Neither feels good about the result.

This is the missing piece of the PDF workflow, and it's a bigger problem than "can we export a PDF from Figma."

Why "Export as PDF" from Figma doesn't solve it

Figma does export to PDF. But the output:

• Has no selectable text on anything that Figma couldn't typeset itself (custom fonts, decorative layout tricks, any overlap).
• Has no paginated flow. If your invoice has a table with 40 rows, Figma gives you one huge PDF page, not a nicely paginated two-pager.
• Has no variable bindings. {{clientName}} is literal text.
• Is a static snapshot. The Figma file stays the source of truth for design, but the PDF produced from it is useless to engineering.

The export is fine for a portfolio preview. It is not a production artifact.

The translation problem

What engineers actually need is code:

<Document>
  <Page size="A4" style={page}>
    <Stack>
      <Heading>{data.clientName}</Heading>
      <Text>Invoice {data.number}</Text>
      <Table rows={data.items} />
      {/* ... */}
    </Stack>
  </Page>
</Document>

Translating a Figma frame into this requires a human. Because:

• Figma has absolute positioning; react-pdf has Flex.
• Figma has arbitrary layer overlap; react-pdf has a stacked tree.
• Figma has rich typography; react-pdf supports a specific font stack registered at runtime.
• Figma has no notion of variable data; your invoice is variable data.

The translation loses information at every boundary. Six months later, when the designer tweaks the header padding from 48 to 40, the engineer has to reverse-translate, figure out which react-pdf primitives controlled that spacing, and change them.

Nobody's happy. The design diverges from the code. Eventually, the design is updated in Figma but not shipped, because "the engineering work to translate is too much for a 4-pixel change."

What would a real bridge look like

A real Figma-to-PDF bridge would:

1. Map Figma primitives to PDF primitives. Frame -> View. Text -> Text. Auto-layout -> Stack.
2. Preserve variables. Figma's "Component Properties" become react-pdf props.
3. Handle the gaps honestly. Some Figma features don't translate. The bridge should flag those, not silently drop them.
4. Round-trip. Designers update Figma, developers get a diff. Developers update the code, designers see the change represented in Figma.

Nobody has built this completely. Figma's plugin API is rich enough; react-pdf's primitives are small enough. The missing piece is the opinionated mapper between them, plus the mental commitment to constrain Figma designs to what can actually translate.

The practical compromise: visual editor + code output

The pragmatic version, which we built at PDFx Builder, is this:

• A visual editor that looks and feels like Figma for the specific case of documents.
• The only primitives available are the ones that map 1:1 to react-pdf (Heading, Text, Stack, Table, etc.). No absolute positioning. No tricks that won't render.
• Every design is stored as a structured tree, not a bitmap.
• One click exports to typed TSX you can drop into a Next.js project.

The designer gets a drawing surface. The developer gets code. The translation is automatic because the designer was always drawing in the code's vocabulary.

This is a weaker claim than "Figma to PDF," and on purpose. It's achievable. And for the use cases where PDFs matter most - invoices, receipts, reports, contracts - the constraints are exactly the ones you'd want.

What this changes about the workflow

Before:

Designer opens Figma -> draws invoice -> sends PNG to dev
  -> dev translates to react-pdf -> PRs code
  -> designer reviews PDF render -> writes feedback
  -> dev iterates -> weeks pass

After:

Designer opens the visual editor -> drags Heading, Stack, Table
  -> clicks Export -> gets TSX
  -> dev commits it
  -> designer iterates directly next time

The loop between "design" and "code" collapses from days to minutes because the design is already in the code's shape.

Where Figma still wins

Figma is still the right tool for:

• The brand system that sits above the document (logo, color palette, typography scale).
• The marketing site that renders the brand.
• Anything that will never be paginated.

Don't abandon Figma. Use it for what it's great at, and give documents a dedicated tool.

The bigger point

"Everything in Figma" is a workflow smell for any artifact that has to survive as code. Documents, emails, data visualizations, ad creatives: each has its own constraints that Figma papers over. Eventually you want a tool that takes the constraints seriously and outputs what engineering actually ships.

PDFs are the clearest case. Your invoice template is not a pretty image. It's a runtime artifact that takes JSON and produces a document. Treat the tool chain that way and the workflow stops hurting.