SVG vs PNG vs PDF vs EPS: Which QR Code File Goes Where

SVG or PNG: which one should you download?

Choose SVG if the code will be printed, placed in a design file, or resized by anyone at any point. Choose PNG if the code will be displayed on a screen at a size you already know. A QR code on a poster, a menu, a label or a business card is an SVG job; a QR code in an email, a slide, a web page or an Instagram post is a PNG job.

The reason is what each file stores. A vector file is an image stored as shapes and coordinates rather than pixels, so it can be redrawn at any size without losing edge definition. A raster file is an image stored as a fixed grid of pixels, so enlarging it past its exported size softens every edge. A QR code is read by a camera that has to tell dark modules from light ones, and soft edges are the one defect that narrows a decoder's margin for error.

When the answer is genuinely unclear, download both. The two files are the same code, they take a second each to export, and having the SVG on hand is what prevents the common failure a year later: a poster that needs the code at 30 cm when the only file left is a 600-pixel PNG from an email thread.

What the four formats are, in one sentence each

SVG is a vector image format written as plain XML text, which is why an SVG QR code opens in any browser, edits in any design tool, and scales without a resolution ceiling. PNG is a lossless raster format with transparency support, which is why it reproduces a QR code's hard edges exactly at the size it was exported. PDF is a page format that can hold either vector or raster content, which is why a PDF QR code has to be inspected rather than assumed. EPS is a vector format based on PostScript, kept alive by print and production workflows that predate PDF.

Note the third row. PDF is the only one of the four whose name does not tell you what is inside it: a PDF can hold clean vector artwork or a photograph of a screen, and both look identical in a file listing. That single ambiguity causes more print problems than the other three formats combined.

Which file goes where

Two rows on this table are worth reading as a pair. A print shop asking for PDF and an engraver asking for SVG want the same thing - geometry the machine can redraw - and they name different formats only because their software chains differ. If a supplier names a format you cannot produce, ask whether they accept SVG; most modern production software does.

What a KoloQR export actually contains

KoloQR, a free QR code generator with circular and custom-shaped QR codes, exports PNG, SVG, PDF and EPS from the same download menu, and copies the SVG markup straight to the clipboard for Figma. The four files are built differently, and the differences decide which one is right for a job.

• SVG: true vector, with the code's parts on named layers and any curved label text converted to outlines, so no font has to be installed anywhere downstream. There is no watermark and no size cap.
• PNG: rendered at 40 pixels per module. A typical short-URL code is 41 modules wide including its quiet zone, which lands at about 1,640 pixels - enough for roughly 14 cm at 300 DPI. The background is whatever colour the design uses, and the area outside a non-square frame is transparent.
• PDF: a single page sized to the code itself at one point per 10 units of geometry, holding the code as a lossless image at 80 pixels per module. That works out at 576 DPI at the page's native size, so it stays above 300 DPI up to roughly 1.9x enlargement - about 28 cm for a code that opens at 15 cm.
• EPS: a real vector conversion, written as PostScript Level 2 paths in RGB. Every module, frame and outlined label becomes a filled path, which is why the file scales like the SVG rather than like the PDF.
• Copy to Figma: the same SVG markup, placed on the clipboard instead of downloaded. Paste lands editable vector layers on the canvas, covered in the guide to copying a QR code into Figma.

Two honest limits follow from that list. The KoloQR PDF is a high-resolution image on a PDF page rather than vector geometry, so a job that will be scaled far beyond A4 should be sent as SVG or EPS instead. And the EPS conversion reads shapes, not embedded pictures: a logo uploaded as your own image file is dropped from the EPS, while the built-in brand logos are vector paths and survive. Check the EPS before sending it if the code carries an uploaded logo.

Everything else about the code is identical across the four files. The payload, the symbol version, the error correction level and the quiet zone are decided when the code is generated, not when it is exported, so no format choice can make an unscannable code scan or a scannable one fail on its own.

SVG: the file to keep, and usually the file to send

Treat the SVG as the master copy of a QR code. It has no resolution, so it prints at 2 cm or 2 m from the same file; it is plain text, so it stays small and survives being emailed and versioned; and it opens in every design tool, so a colleague can place it without asking for a re-export.

SVG also keeps the code editable in the correct sense. The modules stay individual shapes, which means a designer can recolour the code or change its background inside Illustrator or Figma without touching the module grid. What a designer must not do is nudge, stretch non-proportionally, or delete parts of that grid - the arrangement of modules is the data, and rearranging it changes what the code says.

Where SVG gets refused is worth knowing in advance:

• Email: mail clients strip or block SVG for security reasons, so a code in an email body has to be a PNG.
• Social platforms: Instagram, LinkedIn, X, TikTok and YouTube accept raster uploads only.
• Some website builders and template tools: SVG upload is sometimes restricted to paid plans or blocked outright. Canva is the one people hit most often.
• Older office documents: SVG support in Word and PowerPoint is fine on current versions and unreliable on much older ones, so a PNG is the safer attachment when you do not know what the recipient runs.

None of those are reasons to skip the SVG export. They are reasons to keep the SVG as the archive file and export a PNG from it whenever a platform will not take vector.

PNG: right for screens, bounded for print

PNG is the correct choice whenever the display size is known and fixed. It is lossless, so every module edge is reproduced exactly as exported, and it is accepted everywhere, which is the practical reason it remains the default download on most QR generators including KoloQR.

Its limit is arithmetic rather than opinion. A raster QR code prints cleanly up to roughly pixel width divided by 300, times 2.54 centimetres. A 1,000-pixel PNG reaches about 8.5 cm; a 1,640-pixel KoloQR export reaches about 14 cm; past that the module edges begin to spread. The full formula, including the large-format case where 150 DPI is enough, is in the guide to QR code resolution.

For screens, aim for at least 4 CSS pixels per module and export at twice the displayed size so the code stays sharp on high-density displays. A typical short-URL code at 41 modules wants roughly 165 pixels displayed and 330 pixels exported. Sizing below that is where on-screen codes start failing when someone scans them from a phone held at an angle.

The transparency setting deserves a deliberate decision rather than a default. A transparent PNG dropped onto a dark or patterned background loses its quiet zone, and a scanner that cannot find the boundary of the symbol will not decode it. Export on solid white unless you know the code will sit on a light, flat surface.

PDF: what a print shop means when it asks for one

A print shop asking for PDF is asking for a file its workflow can place, proof and impose - not making a claim about vectors. Because a PDF page can hold vector artwork or a raster image, the format alone guarantees nothing about how far the code can be scaled.

Check before sending. Open the PDF and zoom to 1,600%: vector artwork stays perfectly hard-edged at any zoom, while a raster image inside a PDF turns into visible squares. That thirty-second test tells you whether the file can be enlarged for a banner or is fixed near the size it was made at.

If the code needs to be truly resolution-free in a PDF, build the PDF from the SVG rather than exporting one:

1. Download the SVG. Export the code as SVG rather than PNG or PDF - the SVG is the file that holds the geometry.
2. Open it in a vector editor. Illustrator, Inkscape, Affinity Designer and Figma all open SVG directly. Inkscape is free and is enough for this job.
3. Set the document size. Set the artboard or document to the final printed size in millimetres, then scale the code proportionally to fill it, including the quiet zone.
4. Save or export as PDF. Use Save As PDF in Illustrator or Inkscape, or Export as PDF in Figma and Affinity. Keep any option that preserves vector data and do not rasterize.
5. Verify the result. Reopen the PDF and zoom to 1,600%. If the module edges are still hard, the file is vector.
6. Scan the printed proof. Print one page at final size and scan it with an iPhone and an Android phone before the file goes to the run.

A second use of PDF has nothing to do with print: the code inside a document you are sending, such as an invoice, a ticket or an event pack. A QR code placed in a PDF document scans perfectly well from a screen, which is why boarding passes work that way - but keep it at 2 cm or larger on the page, because readers will scan it from a laptop screen at arm's length.

EPS: a legacy format with two live uses

Export EPS when a supplier asks for it by name, and not otherwise. Adobe has treated PDF and AI as the successors to EPS for years, and most current software handles SVG or PDF better - but screen printers, embroiderers, sign makers and older prepress systems still list EPS as their required format, and those requests are real.

Two EPS properties change how you use it. EPS does not support live transparency, so any transparent area is flattened when the file is written - a reason to export a code on a solid background rather than expecting the paper colour to show through. And EPS carries colour as RGB in most exports, including the one KoloQR writes, so a printer running CMYK will convert it. For a pure black code that conversion is uneventful; for a brand colour, ask the printer for the CMYK build you want rather than letting the conversion decide.

The trap specific to QR codes is what does not survive the conversion. Because EPS is written from the shapes in the artwork, anything that is an embedded picture rather than a shape - most commonly a logo you uploaded as your own PNG - is skipped. The code itself is unaffected and still scans; the logo simply is not there. Open the EPS once before sending it and you will see the difference immediately.

Formats that damage a QR code: JPEG, WebP and the screenshot

Never save or send a QR code as JPEG. JPEG compresses by discarding high-frequency detail, and a QR code is almost nothing but high-frequency detail: thousands of abrupt black-to-white transitions. The result is faint ringing around every module, which survives into print and reduces contrast exactly where the decoder measures it.

The failure is quiet rather than obvious. A JPEG-damaged code usually still scans on a bright screen and then stops working on absorbent paper, in dim light, or at an angle - which is precisely the situation a printed run meets. Because the artefacts are baked into the pixels, re-saving that file as PNG later does not repair anything.

The screenshot row is the one that reaches print most often. A code screenshotted from a preview, pasted into a document and sent to a printer arrives at roughly 100 DPI with its margin clipped, and the printer has no way to tell that a better file existed. Regenerating the code takes less time than the email asking whether the screenshot will do.

How to tell which kind of file you have been sent

The extension is a claim, not a guarantee. When a code arrives from a client, an agency or an old archive, four checks settle what it really is in about a minute.

1. Open the SVG in a browser and zoom to 1,000%. A real vector stays hard-edged. If it turns into squares, the SVG is a raster image wrapped in an SVG tag - which is a real thing some converters produce.
2. Check the file size. A vector QR code is usually a few kilobytes to a few tens of kilobytes. A multi-megabyte SVG or EPS almost always contains an embedded bitmap.
3. Zoom the PDF to 1,600%. Same test, same tell: vector stays crisp, raster pixelates.
4. Look for the quiet zone. Whatever the format, there must be a clear margin of four modules on all four sides. A tightly cropped file has already lost something no format can restore.

If any check fails, regenerate the code rather than repairing the file. Scan the existing code with a phone to read its destination, paste that destination into a generator, and export fresh files. The new code is mathematically clean, and you have also verified where the old one actually points - worth knowing before reprinting anything.

Converting between formats without breaking the code

Converting down is safe and converting up is not. Vector to raster - SVG to PNG, EPS to PNG - is a clean operation at any size you choose. Raster to vector - PNG to SVG - cannot recover geometry that was never in the file, and an automatic trace produces slightly rounded, slightly misaligned modules that eat into the decoder's margin.

If a raster code truly cannot be regenerated - the original file is gone and the client wants it larger - upscale by a whole-number factor with nearest-neighbour interpolation rather than bicubic or AI upscaling. Nearest-neighbour duplicates pixels and keeps the edges hard; smoothing algorithms blur exactly the boundaries a scanner measures.

Whichever route you take, scan the result before it ships. A converted code that scans on an iPhone and an Android phone, printed at final size on the real stock, is a converted code that works; anything less is an assumption.

Common file-format mistakes, and how they show up

The pattern across these rows is that format problems rarely announce themselves. The code looks right on the screen where it was made, and fails on the material where it lives - which is why the last step of any format decision is a printed proof scanned in the light the code will actually be read in.

Choosing the format before the design starts avoids most of the list. If the code will be printed, generate it, export the SVG, and hand that file to whoever builds the layout. The generator produces all four formats from the same code, so the decision costs nothing but attention. Format is settled at the fourth of nine checks; the print checklist runs through the rest in order.