How to convert a pdf to the right version for print production
- Step 1Read the supplier's exact version requirement — Find the required PDF version (and any PDF/X standard) on the supplier's spec sheet. PDF/X-1a maps to PDF 1.4; PDF/X-4 maps to PDF 1.6. If they just say 'PDF 1.4', target 1.4.
- Step 2Embed fonts and set colour BEFORE this step — Version conversion won't fix fonts or colour. Make sure all fonts are embedded (use the Font Subsetter to embed/subset) and that colour is correct in your design tool first. This tool is the last small step, not the preflight.
- Step 3Open the converter and drop the artwork — Load the print-ready PDF into the PDF Version Converter. It runs locally in your browser via pdf-lib — the artwork is never uploaded. One file at a time.
- Step 4Select the supplier's version in the dropdown — Pick PDF 1.4, 1.5, 1.6, or 1.7 to match the spec (default is 1.7). The output is saved with object streams off for 1.4 and on for 1.5+, and the header is set accordingly.
- Step 5Download and run the supplier's preflight — Save
<name>.version-converter.pdfand run it through the supplier's preflight or a desktop checker. Version conversion alone doesn't guarantee PDF/X compliance — confirm colour, fonts, and output intent pass. - Step 6Submit to the print supplier — Once preflight is clean, send the version-correct file. Keep the original master in case you need to re-export at a different version.
PDF/X standard → PDF version → what this tool does
Version conversion matches the version flag. PDF/X compliance needs more, listed in the last column.
| PDF/X standard | Base PDF version | This tool sets the version? | Still needs (not done here) |
|---|---|---|---|
| PDF/X-1a | PDF 1.4 | Yes — target 1.4 (object streams OFF) | CMYK colour, embedded fonts, output intent |
| PDF/X-3 | PDF 1.4 | Yes — target 1.4 | Managed colour + output intent, embedded fonts |
| PDF/X-4 | PDF 1.6 | Yes — target 1.6 (object streams ON) | Output intent, embedded fonts, live transparency rules |
| Plain 'PDF 1.5/1.6' RIP spec | 1.5 or 1.6 | Yes — match the number | Whatever the RIP separately requires (often fonts/colour) |
What the version converter does and does NOT do for print
Read this before assuming version conversion makes a file press-ready.
| Print concern | Handled here? | Use instead |
|---|---|---|
| PDF version flag + serialization | Yes | — |
| RGB → CMYK colour conversion | No | A colour-managed design/preflight tool |
| Embedding missing fonts | No (embeds nothing new) | Font Subsetter to subset/embed |
| ICC output intent | No | A PDF/X preflight tool |
| Flattening transparency | No | PDF Flatten (note: it flattens form/annotations, not press transparency) |
| Downsampling / re-compressing images | No (images pass through unchanged) | PDF Compress (Lossy) only if you must shrink |
Cookbook
Where version conversion fits in a realistic print-prep sequence — and where it can't help.
Supplier requires PDF/X-1a (PDF 1.4)
The spec says PDF/X-1a. Set the version to 1.4 as the last step, after colour and fonts are already correct in the source.
Already done in design tool: CMYK + embedded fonts + output intent This step: PDF Version Converter → target 1.4 Output: %PDF-1.4, object streams OFF, vector text intact Then: run supplier preflight to confirm full X-1a compliance
PDF/X-4 workflow needs PDF 1.6
An X-4 RIP expects PDF 1.6 and tolerates live transparency. Target 1.6 to keep the compact structure.
Input: %PDF-1.7 export from layout app Target: PDF 1.6 Output: %PDF-1.6, object streams kept ON Note: colour/output-intent still verified separately
Embed fonts first, then set the version
The RIP rejected a file for a non-embedded font AND a too-new version. Fix fonts before the version step — version conversion embeds nothing.
Step 1: Font Subsetter → embeds + subsets the used glyphs Step 2: Version Converter → target 1.4 Wrong order (version first) leaves the missing font unembedded — the RIP still rejects it.
Old RIP can't parse the file at all
Not a colour or font issue — the RIP errors before preflight because it can't read the 1.7 compressed structure. 1.4 turns object streams off so it parses.
Symptom: RIP errors on load, before any preflight report Target: PDF 1.4 (object streams OFF) Output parses on the old RIP; now run normal preflight.
What it WON'T do — RGB stays RGB
A common misconception: converting the version does not fix colour. An RGB file converted to 1.4 is still RGB and will fail a CMYK-only preflight.
Input: RGB artwork, %PDF-1.7 Target: PDF 1.4 Output: %PDF-1.4 but STILL RGB Preflight result: fails 'colour space not CMYK' Fix colour in your design/preflight tool, not here.
Edge cases and what actually happens
RGB colour wasn't converted to CMYK
Not handledVersion conversion does not touch colour. An RGB file stays RGB after converting to any version and will fail a CMYK-only preflight or print with shifted colours. Convert colour in a colour-managed design or preflight tool before or after this step — this tool only sets the version flag and serialization.
A font isn't embedded
Not handledThe converter embeds nothing new — if a font was missing, it's still missing after conversion, and the RIP will substitute or reject. Embed and subset fonts first with the Font Subsetter, then run the version step.
No ICC output intent for PDF/X
Not handledPDF/X requires an output intent (a destination colour profile). Version conversion does not add one, so a 1.4 file from this tool is not automatically PDF/X-1a. Use a dedicated PDF/X preflight tool to set the output intent; treat the version step as just the version baseline.
Press transparency expected to flatten
Not flattenedTargeting 1.4 removes optional-content layers but does not flatten live transparency to the way an X-1a RIP expects (X-1a disallows live transparency). This tool's PDF Flatten sibling flattens form fields and annotations, not press transparency. Flatten transparency in a print preflight tool for an X-1a job.
Images expected to be downsampled
UnchangedImage streams pass through the rebuild untouched — there's no DPI downsampling or re-compression. If the supplier needs images at a specific maximum DPI, handle that in your export settings or with PDF Compress (Lossy); version conversion won't change image resolution.
Interactive elements or signatures present
DroppedForm fields, bookmarks, and any digital signature do not survive the page-copy rebuild — fine for most print artwork, which is static. If your file had a proofing signature you need to keep, sign after converting with PDF Digital Signature.
Artwork was supplied encrypted
DecryptedThe output is always unencrypted; the converter reads past any input encryption. That's usually correct for a RIP (which needs full access), but if your asset-management system requires encryption, re-apply it after with PDF Password Protect.
Producer / ModDate metadata changed
ExpectedThe save updates document metadata, so the Producer and modification date reflect the conversion. Most print workflows ignore these, but if your asset tracking reads them, note that they'll differ from the original export. Scrub with PDF Metadata Scrubber if needed.
Artwork exceeds the tier size or page cap
400 limitHigh-resolution print PDFs are large. Free tier caps at 2 MB / 50 pages, Pro at 50 MB / 500 pages, and Pro+Media at 500 MB / 2,000 pages. A large CMYK brochure will need a paid tier; the Pro+Media 500 MB ceiling suits most press files.
Output looks slightly bigger after targeting 1.4
Expected1.4 turns off object-stream/xref compression, so a 1.4 file can be a little larger than the 1.7 source. For print this is irrelevant — fidelity matters, not bytes. Don't run a lossy compressor on press artwork to 'fix' the size; that degrades image quality.
Frequently asked questions
Does converting the version make my PDF PDF/X compliant?
No — it only sets the version baseline. PDF/X-1a is built on PDF 1.4 and PDF/X-4 on PDF 1.6, so matching the version is necessary but not sufficient. Full compliance also requires CMYK (or managed) colour, all fonts embedded, an ICC output intent, and conformance to the standard's feature rules — none of which this tool does. Use a dedicated PDF/X preflight tool for the rest and treat version conversion as the version step only.
Will this convert my RGB artwork to CMYK?
No. The converter changes the version flag and re-serializes the file; it doesn't touch colour at all. An RGB file stays RGB and will fail a CMYK-only preflight or shift on press. Do colour conversion in your colour-managed design or preflight tool — this is purely a version operation.
Does it embed fonts for me?
No. It embeds nothing new — a non-embedded font remains non-embedded after conversion, and the RIP will substitute or reject. Embed and subset fonts first with the Font Subsetter, then set the version. Always embed before the version step, not after.
Which version does my print supplier want — 1.4 or 1.6?
Match their spec. PDF/X-1a (the most conservative, CMYK-only, no live transparency) is based on PDF 1.4. PDF/X-4 (allows live transparency and colour management) is based on PDF 1.6. If the spec just names a number, use that number. When unsure, 1.4 is the safest because it forces the older, most widely parsed serialization.
Will converting the version reduce image quality?
No. Image streams pass through the rebuild untouched — there's no downsampling or re-compression. This is deliberate: you don't want a print tool silently degrading artwork. If a supplier needs a maximum image DPI, set that in your export, not here. (The separate lossy compressor does re-encode images, so don't use it on press artwork unless you must shrink the file.)
Does it flatten transparency for an X-1a job?
No. Targeting 1.4 drops optional-content layers but does not flatten live transparency the way an X-1a RIP requires (X-1a disallows live transparency). Transparency flattening for print needs a dedicated preflight tool. This tool's Flatten sibling handles form fields and annotations, which is a different operation.
What's the right order: version conversion or font embedding first?
Embed fonts (and fix colour) first, then convert the version as the last small step. Version conversion only re-serializes what's already in the file — if you convert before embedding, the missing font is still missing afterward. Sequence: design tool (colour) → Font Subsetter (fonts) → version converter → supplier preflight.
Is my client's artwork uploaded anywhere?
No. The conversion runs entirely in your browser via pdf-lib — proprietary or NDA-bound artwork never leaves your device. Only an anonymous usage counter is recorded when you're signed in, and you can opt out. That's important for agencies and pre-press shops handling confidential brand assets.
The output is bigger than my original — is that a problem for print?
No. Targeting 1.4 turns off the object-stream/cross-reference compression that 1.7 uses, so the same artwork can be a little larger. For print, fidelity is what matters and the size difference is irrelevant. Resist the urge to run a lossy compressor on press files to shave bytes — it re-encodes images and harms quality.
Can I convert a whole job folder of artwork at once?
The browser tool does one file per run. For a multi-file job, the converter is available via the @jadapps/runner on a paid tier: fetch GET /api/v1/tools/pdf-version-converter, pair the runner, and POST each file with { "version": "1.4" } (or 1.6 for X-4) to 127.0.0.1:9789/v1/tools/pdf-version-converter/run. Files are processed locally — artwork stays on your machine.
Can I target PDF 2.0 or PDF/X-6?
No. The dropdown offers only 1.4, 1.5, 1.6, and 1.7. PDF/X-6 is based on PDF 2.0, which this tool doesn't output. If your supplier specifically requires PDF 2.0 / PDF/X-6, you'll need a desktop preflight tool that supports ISO 32000-2.
Does anything visible change in the artwork?
For standard print artwork, no — text and vector line art stay crisp because this re-serializes rather than re-renders. The only structural loss is optional-content layers when targeting 1.4 (a 1.5 feature). Colour, images, and geometry are preserved exactly; what you must still verify separately is colour space, font embedding, and output intent.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.