PDF editor SDK – open a PDF and edit it as layers

Most PDF tooling treats a document as something to view or annotate on top of. Polotno takes a different route: it parses the PDF into a design schema, so text stays text, images stay images, and vector artwork stays paths. The result is a document your users can genuinely edit on a canvas — then export back out as a vector PDF.

The round trip

Three steps, all available in the browser or on a server.

import { pdfToJson } from '@polotno/pdf-import';
import { jsonToPDFBlob } from '@polotno/pdf-export/browser';
import { createStore } from 'polotno/model/store';

// 1. Parse
const json = await pdfToJson({ pdf: await file.arrayBuffer() });

// 2. Edit — programmatically, or hand the store to the editor UI
const store = createStore({ key: 'YOUR_KEY' });
store.loadJSON(json);
await store.waitLoading();

// 3. Export as vector PDF, with text still selectable
const blob = await jsonToPDFBlob(store.toJSON());

Between step two and step three you can do anything the SDK allows: change copy, swap a logo, recolour a background, delete pages, add elements, or apply a template. The editor UI is the same canvas used for images, text, and video, so a user who can edit a social post can edit a PDF.

Try the parse step without writing code in the PDF to JSON tool, which runs the same pdfToJson() function in your browser.

What you get back from a PDF

The parser emits typed elements, not a flattened bitmap:

text — content, font family, size, weight, fill, position, rotation, alignment. Rich-text styling survives: mixed weights inside a paragraph, justified text, multi-column bodies, footnotes, and dotted tables of contents.
table — ruled grids are reconstructed as real table elements with editable cells, borders, and alignment, not as loose lines and text.
image — base64 source, crop region, position, opacity.
svg — vector artwork re-emitted as inline SVG with position and size.
line — stroke segments with colour, dash, and position.

Bullet columns import as a single text element with real <ul> markup rather than glyphs faked with spaces. Damaged embedded fonts are repaired before use, and each page is sized from its own viewport, so a document that mixes page sizes or rotations does not get forced into one box.

Pages are sized at the PDF's TrimBox, with any bleed carried outside the page, so a print-ready file round-trips without losing its geometry. Password-protected files import by passing the password option to pdfToJson.

Because every element carries explicit coordinates, edits are precise and repeatable. The full shape is documented in the PDF import reference and the design schema.

Editing programmatically

The same API that powers the UI is available headlessly, which makes scripted edits straightforward.

// Replace a placeholder across every page
store.pages.forEach((page) => {
  page.children
    .filter((el) => el.type === 'text' && el.text.includes('{{name}}'))
    .forEach((el) => el.set({ text: el.text.replace('{{name}}', customer) }));
});

Typical uses: correcting a price across a catalogue, localizing a template, injecting a customer name into a contract draft, or normalizing brand colours across a set of supplied documents.

Export fidelity

There are two export paths, and the difference matters. store.saveAsPDF() is built in and raster — each page is flattened to an image, which is right when you need pixel parity with the canvas. @polotno/pdf-export is vector: text is embedded as subsetted fonts and stays selectable, files are smaller, and output scales for print. Use vector unless you specifically want the flattened version.

Vector export runs in the browser (jsonToPDFBlob) or under Node (jsonToPDF), and supports CMYK, spot colours, bleed, crop marks, and PDF/X-4 or PDF/X-1a — see PDF export.

You are not limited to PDF on the way out. The same edited design exports to PNG, JPG, SVG, HTML, or PPTX.

Honest limits

Worth knowing before you scope a build:

Scanned PDFs contain no text layer. The parser returns image elements and nothing to edit as text. Run OCR first with a dedicated tool, then import the text-augmented file.
Form fields come in as text, not as fields. The text a form carries is imported and stays editable, but AcroForm widgets are not parsed as interactive fields, so a filled form loses its form-ness on the way through.
Annotations arrive flattened into the page. There is no editable comment or markup layer.
Redaction in the security sense is not provided. Deleting an element removes it from the design, which is an editing operation, not a certified redaction.
Exotic layouts — heavily ligatured scripts, unusual embedded font subsets, and complex transparency groups can shift on re-export. Test with your own documents.

If those limits rule Polotno out, they are genuine reasons to pick a document-processing SDK instead.