pdf.to.design is a Figma plugin by divRIOTS that imports PDF pages into Figma as editable design layers - text, images and vectors reconstructed as Figma objects you can rework. It is genuinely useful for turning design-origin PDFs into new material, with two caveats: fonts substitute, and complex layouts need a cleanup pass. This guide covers the workflow, the free companion tools (SVG conversion, image extraction), and when manual routes beat the plugin.
Quick answer: pdf.to.design imports PDF pages into Figma as editable layers - genuinely useful for reworking design-origin PDFs into new material. Text and vectors arrive as objects; fonts substitute; complex layouts need cleanup; scans stay flat images. The free support workflow - extracting images and converting pages to SVG locally - pairs with it or replaces it, task depending.
On this page
- What pdf.to.design is and who makes it
- How to import a PDF into Figma step by step
- What reconstructs well - and what does not
- The use cases it was built for
- The free companion workflow (SVG, extraction, renders)
- Plugin vs manual routes: choosing per task
- Pricing and terms: what to check before relying on it
- Fidelity expectations: the reconstruction contract
- FAQ
What pdf.to.design is and who makes it
pdf.to.design is a Figma plugin from divRIOTS - a studio specializing in design-tool importers (their plugin family also covers bringing content in from other ecosystems into Figma). The product's single job: take a PDF and rebuild its pages as Figma layers.
Understanding its family clarifies its role: Figma is the design industry's collaboration hub, but it is not a PDF reader - PDFs land in Figma as flat images at best. The plugin bridges that gap by parsing the PDF (the same parsing family as Illustrator's PDF import, reviewed elsewhere on this blog) and reconstructing text runs, images and vector paths as native Figma objects.
The user this serves is specific and common: anyone whose design work lives in Figma but whose inputs arrive as PDFs - supplier decks, old brochures, client print pieces, exported design documents from other tools. Before such plugins, the workflow was screenshot-and-trace; after it, the workflow is import-and-cleanup. That difference in kind, not degree, is why the plugin found its audience.
How to import a PDF into Figma step by step
The mechanics, with the cleanup expectations stated upfront:
Step 1 - Install the plugin. In Figma: Resources > Plugins, search "pdf.to.design", and run it (first run prompts installation from the Figma Community listing).
Step 2 - Feed it the PDF. The plugin prompts for a file - select your PDF. Depending on the version, you choose which pages to import; choose deliberately (importing a 60-page deck when you need two pages multiplies cleanup).
Step 3 - Let it reconstruct. The plugin parses and rebuilds: text becomes text layers, images become image fills, vectors become shape layers, positioned on a frame per page. Larger files take proportionally longer.
Step 4 - The cleanup pass (the real work). Open the imported frame and inventory the layers: this is where your judgment enters. Expect to: regroup elements that arrived fragmented, fix or accept font substitutions, delete reconstruction debris (empty groups, duplicate shapes), and re-link any images that arrived as unexpected fills. Simple pages clean up in minutes; dense ones are projects.
Step 5 - Save the source. The imported Figma copy is a derivative. The original PDF remains the master - file it, because six months from now someone will ask for the "real" version.
Total time for a simple two-page brochure into usable layers: typically under fifteen minutes including cleanup - versus hours of manual tracing before plugins existed.
What reconstructs well - and what does not
Set expectations per content type and the tool stops disappointing:
| Content | Reconstruction quality | Notes |
|---|---|---|
| Body text | Good | Arrives as editable text layers; fonts substitute unless matched |
| Simple shapes/vectors | Good | Paths arrive editable and clean |
| Embedded images | Good | Arrive as image fills at embedded resolution |
| Complex layouts | Workable but fragmented | Expect regrouping; masking artifacts possible |
| Tables | Workable | Often arrive as loose text + lines; rebuild deliberate tables |
| Effects/transparency | Mixed | Flattened or approximated; restyle as needed |
| Outlined text | As shapes | Arrives as vector outlines, not editable text (by definition) |
| Scanned pages | Flat images | No structure exists to reconstruct - image frames only |
| Forms/signatures | Not meaningfully | Interactive elements do not survive as such |
The pattern: content that is design data reconstructs as design data; content that is only appearance (scans, flattened effects) arrives as appearance. The plugin cannot recover structure that was never stored - a boundary worth knowing before promising a client "the editable version".
The use cases it was built for
Where the plugin genuinely earns its keep - the recurring jobs that justify its existence:
Legacy material modernization. The 2019 brochure needs to become this year's web content. Import the PDF's layouts as a starting point, restyle with current brand, adapt to web dimensions - reconstruction turns an archive into raw material.
Supplier and client asset extraction. "Use the layout from this PDF" arrives weekly in design work. Import beats tracing, and beats screenshotting, for pulling a supplier's composition into your working file.
Design-export round trips. Designs exported to PDF by other tools (or past agencies) come back as workable layers rather than dead images - the round-trip rescue that keeps projects moving when source files are gone.
Content migration into design systems. Print-era content (fact sheets, one-pagers) being absorbed into a living design system: import once, decompose into components, and the system grows from the archive.
What these share: the PDF is design material being transformed into new design. When the task is instead document integrity - the contract that needs two words changed - this is the wrong family of tool, and the direct-editing guides on this site cover that family.
The free companion workflow (SVG, extraction, renders)
Whether or not the plugin is in your stack, three free local tools complete the PDF-into-design workflow - and cover the tasks where the plugin is weakest:
Vector routes: PDF to SVG. The free PDF to SVG converter exports pages as SVG - the universal vector format that Figma, Illustrator, Inkscape and friends all import. SVG arrives as clean vector geometry (paths), which suits logo and artwork extraction especially well. Local, instant, no account.
Image routes: Extract Images. The free Extract Images tool pulls every embedded image from the PDF at native resolution - the correct way to get the photos and logos out (screenshotting degrades; extraction does not). Rebuild with them in any design tool.
Reference routes: high-res page renders. PDF to PNG at 200-300 DPI produces clean page images - the right substrate for tracing jobs, layout reference, or quick placement when layers are not actually needed.
The composed workflow that many teams settle on: SVG for vectors, extraction for images, renders for reference - all free and local - with the plugin adding value precisely where layer reconstruction saves real time. Tools that compose beat tools that compete; this is composition in practice.
Plugin vs manual routes: choosing per task
The decision table for the recurring "which route" moment:
| Task | Best route | Why |
|---|---|---|
| Rework a brochure into new material | Plugin import | Layer reconstruction pays for itself in cleanup time saved |
| Get the logo out of a PDF | Extract Images / SVG | Native quality, free, no cleanup |
| Trace a layout into a new design | High-res render + manual build | Reference is all you need; layers would mislead |
| Edit two words in a document | Direct PDF editor | Design tools are the wrong family for document integrity |
| Batch-convert pages for a design system | SVG conversion | Deterministic, scriptable, free at any volume |
| One-off complex-page cleanup project | Plugin import + patience | Reconstruction + manual cleanup beats full manual rebuild |
The routing principle: layer reconstruction is a service with a cost (cleanup, substitution, pricing terms). Deploy it when the reconstruction saves more time than its cost - the brochure-to-web job - and route around it when a free extraction gives you the same assets without the tax.
Pricing and terms: what to check before relying on it
Plugin economics follow the freemium model, and the terms worth verifying on its Figma Community listing before building workflows on it:
Usage limits on the free tier - pages per month or imports per week are the common shape. Size your reliance accordingly, or budget for the paid tier.
Export rights on your imported designs. The layers in your Figma file are yours; confirm nothing in the terms constrains their use (standard expectation, worth the thirty-second read).
Update cadence and support. Plugins are living software; a maintained changelog and responsive support separate tools to build on from tools to trial.
The dependency question. Any plugin is a dependency: if it disappears tomorrow, your already-imported designs are safe (they live in Figma), but the workflow needs the manual routes as backup - which is exactly why this guide pairs the plugin with the free local tools. Workflows built on tool + fallback survive; workflows built on tool alone grieve.
None of this argues against the plugin - it argues for reading its current terms once, the same diligence you would apply to any component in a professional pipeline.
Fidelity expectations: the reconstruction contract
The implicit promise every importer makes deserves explicit wording, because misunderstood reconstruction is the source of most one-star reviews in this category:
What reconstruction promises: the page's content arrives as editable layers - approximately. Text is text (in some font), shapes are shapes (approximately shaped), images are images (at embedded resolution).
What it does not promise: pixel fidelity to the original; font identity without your fonts; grouping that matches the designer's intent; preservation of effects, or recovery of structure that was flattened before the PDF existed.
The professional usage contract that follows: treat imports as starting points, not copies. Rename it in your head: this is "reconstruction of" the PDF, not "the PDF, in Figma". Keep the master; expect cleanup; budget for substitution. Teams that internalize this love the tool category; teams that expect Xerox fidelity write the angry reviews.
And the boundary case that settles most arguments: if a task requires the PDF's exact appearance, the answer is not better reconstruction - it is a different tool family (direct PDF editing, or print-grade workflows). Reconstruction serves re-creation; fidelity lives elsewhere. Knowing which side of that line your task sits on is worth more than any feature comparison in this space.
The reverse direction: designs into PDFs done right
The workflow has two halves, and the export half - design tool to PDF - is where quality is won or lost. The settings that matter in Figma and peers:
Export for print: use the design tool's PDF export with fonts embedded (Figma's PDF export embeds them) and images at full resolution; for professional print handoff, export at final size and check bleed expectations (design canvases may need bleed frames built in). The export dialog's defaults suit screens, not presses - adjust deliberately.
Export for sharing: standard PDF export suffices; compress afterwards (Compress PDF) if image-heavy designs exceed email limits - compression after export beats degrading the export itself.
Export for reuse: if the PDF's destination is another import later, remember the reconstruction contract from above - effects flatten and layers merge on the way in. For long-lived assets, SVG (vectors) and native formats preserve editability better than any PDF round trip.
The naming and versioning hygiene: exported PDFs are deliverables - date and version them (proposal-v3-2026-10-08.pdf), because PDFs sent to clients become references that outlive the design file's own history.
Teams that treat export as deliberately as import get round trips that neither lose quality nor surprise anyone - and the complete loop (PDF in via reconstruction or extraction, design work, PDF out via deliberate export) is, end to end, free except for the design tool itself.
When the source PDF is a scan: the realistic rebuild path
A large share of PDFs people want in design tools are scans - photographed or scanned print material. The plugin route gives them nothing (flat images in), so the honest path is a deliberate rebuild:
Step 1 - Assess the source honestly. A clean 300 DPI scan of a simple layout can be rebuilt in under an hour; a skewed, low-res photocopy is a re-creation, not a reconstruction - say so to whoever is expecting "the editable version" before promising it.
Step 2 - Extract or render the imagery. Pull whatever images the scan carries (Extract Images) or render clean page images (PDF to PNG) as tracing references.
Step 3 - Recover the text if it matters. Run OCR on the scan to recover the words as text - proofread the output (scan quality drives recognition), then paste clean text into the design tool rather than retyping from squinting.
Step 4 - Rebuild the layout deliberately. Reference image on a locked layer, fresh text and shapes above it - the tracing workflow every designer knows. The rebuild will differ from the original; where fidelity matters, that difference is the deliverable's risk, and should be flagged at step 1.
Step 5 - Replace the original where it lives. Once rebuilt, the new design's exports supersede the scan in your systems - and the scan retires to the archive where scans belong.
The scan path is more work than the plugin path because it should be: it is re-creation, and pretending otherwise produces brittle imports and disappointed stakeholders. The tools in the chain are all free; the cost is honest labor.
Build-system hygiene for imported designs
Reconstructed layers arrive as debris by nature - and the cleanup pass goes faster with a standard that defines what "done" looks like. The import hygiene that design teams converge on:
Name and group as you clean. "Imported-frame-1-copy-4-shape" names compound confusion; rename top-level groups semantically (hero, nav, body, footer) during cleanup, and every future edit gets faster. Layer hygiene is a gift to your future self, and to whoever inherits the file.
Standardize text styles immediately. Imported text carries dozens of near-identical font-size/weight combinations from the reconstruction. Collapse them into your design system's text styles during cleanup - the imported design then behaves like a native one, and brand consistency is enforced rather than remembered.
Re-link images to proper fills or components. Images that arrived as odd fills become real assets - named, sized, and if recurring, components. The design system absorbs the import instead of harboring it.
Delete reconstruction debris ruthlessly. Empty groups, invisible shapes, duplicate paths behind visible ones: the importer's scaffolding. A sweep at the end of cleanup (select-all, inspect, delete) leaves a file that exports clean and weighs what it should.
Document the provenance in the file. A note on the first frame - "Imported from supplier-brochure-2024.pdf on 2026-10-08; fonts substituted (X->Y); original in /archive" - costs thirty seconds and answers the question this file will generate in six months.
None of this is specific to pdf.to.design; it is the standard that makes any imported design maintainable. Cleanup with a standard ends at a native-quality file; cleanup without one ends at a tidier debris field. The difference is an afternoon either way - spent once, or paid forever.
Working across design tools: the SVG lingua franca
Figma is this guide's context, but design reality is multi-tool - Illustrator for print, Inkscape for budget conscience, Blender-adjacent pipelines, web teams in other environments - and the inter-tool question ("how do I move this between tools?") has a lingua franca: SVG.
Why SVG is the universal vector handoff. SVG is an open, text-based vector format that every serious design and vector tool imports and exports. Where native formats (.fig, .ai, .sketch) are tool-locked, SVG is the neutral ground - imperfect for full design fidelity (effects and complex features vary), perfect for geometry, text and basic styling.
The PDF-to-SVG bridge in practice. Convert a PDF page to SVG (free, local) and that page's vector geometry opens in any of your tools - the artwork extraction that used to require Illustrator's PDF import is now a conversion away. Logos, icons, diagrams and line art travel this road especially well.
Where SVG falls short, honestly: text may arrive as paths (uneditable) or with font references (breakable) depending on the converter; effects and blends simplify; and complex pages produce heavy files. For artwork and geometric content it excels; for full-page design fidelity, plugin reconstruction or native imports remain the stronger routes.
The multi-tool workflow this enables: PDF assets flow to SVG, open everywhere; images flow through extraction; pages render to PNG for reference - a three-lane pipeline that serves every design tool you use, from one free local toolbox. The plugin question then becomes what it should be: a convenience for Figma-specific reconstruction, not the only bridge in town.
A complete worked project: brochure archive to web landing page
The full workflow, end to end, in the shape it arrives in real work: a 2019 printed brochure PDF must become this year's web landing page. Every tool in this guide appears; every lesson applies.
Phase 1 - Asset recovery (free, 15 minutes). Extract all embedded images (Extract Images - photos and the logo at native quality), convert the key pages to SVG (PDF to SVG - the vector ornaments and line art), render pages to PNG (PDF to PNG - reference board material). The archive is now raw material.
Phase 2 - Structure recovery (15 minutes). Run OCR on the brochure to recover the copy as text; proofread it (scan-era brochures have recognition errors). The words now exist as text - no retyping from squinting at renders.
Phase 3 - Reconstruction or reference (30-60 minutes). If the brochure's layout is worth keeping: import via the plugin into Figma, clean up per the hygiene standard, and mine the structure. If the layout is dated (it is, it's 2019): use the PNG renders as a content checklist and design fresh - the extraction gave you everything you needed either way.
Phase 4 - Rebuild for the destination (design work). Build the landing page with the recovered assets: text pasted clean, images re-linked at full quality, vectors imported from SVG. The old brochure's content now lives in a native, editable, web-appropriate form.
Phase 5 - Export and retire the original (10 minutes). Export the deliverables the destination needs, archive the brochure PDF as the record, and note the provenance in the design file per the hygiene standard.
Total: a couple of hours for work that was, before importers and free extraction, a multi-day re-creation job. Every tool in the chain was free; the only paid thing in the room is the design tool you already had. That is the complete guide, demonstrated - and the checklist transfers to your next archive project unchanged.
FAQ
What is pdf.to.design? A Figma plugin by divRIOTS that imports PDF pages into Figma as editable design layers - text, images and vectors reconstructed as Figma objects.
How do I convert a PDF into an editable Figma design? Run the pdf.to.design plugin from Figma's plugin panel, select your PDF, choose pages, and let it reconstruct - then plan a cleanup pass for fragments, fonts and grouping.
What is pdf.to.design good for? Reworking design-origin PDFs: legacy brochures into web content, supplier layouts into working files, design-export round trips, and archive-to-design-system migration.
What are pdf.to.design's limitations? Font substitution, layout fragmentation on complex pages, flat images for scans, no meaningful form/signature import, and freemium usage terms - reconstruction, not fidelity.
Is pdf.to.design free? Freemium - a free tier with usage limits and paid plans; check its Figma Community listing for current terms. The companion tools (SVG conversion, image extraction, renders) are free outright.
Can I get PDF content into Figma without the plugin? Yes - PDF to SVG for vectors, Extract Images for assets, high-res PNG renders for tracing: all free, local, and tool-agnostic.
Why does my imported PDF look different in Figma? Import is translation between formats - fonts, kerning, grouping and effects are approximated by design. Treat imports as starting points, never as copies of the original.
Can scanned PDFs be imported as editable layers? No - scans are flat images with no structure to reconstruct; they arrive as image frames. Extract the imagery or OCR the text and rebuild deliberately.
Get your PDF into design - free where possible
Layers when reconstruction pays: try pdf.to.design in Figma. Assets always: PDF to SVG, Extract Images and PDF to PNG run free and local at PDFEditorFree - no account, nothing uploaded.