SVG vs PNG vs PDF output: which format for which integration

PNG: the raster default, and the only format with full feature support

PNG is a rasterized bitmap at whatever resolution you request (1 to 4096px, capped by your plan), and it's the only one of the three formats that supports every option in the request: custom colours, module and finder shapes, image roundness, and a logo composited into the centre. If your integration needs the full customization surface, PNG is the format that actually delivers all of it.

It's also the right default for anything screen-based: emails, app UI, a link-in-bio page, a dashboard preview. The resolution cap per plan (1024px Starter, 2048px Pro and Growth, 4096px Enterprise) matters more for PNG than for the other two formats, since it's a fixed pixel grid, not something that can be rescaled later without visible quality loss.

SVG: vector output, but logos are silently dropped on a single generate call

SVG returns actual vector markup, a single compound path for the QR modules rather than a pixel grid, so it scales to any size (a business card or a billboard) without the blur or blocky edges PNG would show at extreme scale-up. That's the entire appeal of choosing SVG: resolution stops being a decision you have to get right upfront.

The part that isn't obvious from the API spec alone: request logoUrl or logoDataUrl alongside format: svg on a single POST /api/v1/generate call, and the response comes back as a clean SVG with no error and no logo. Logo compositing happens via sharp, which rasterizes onto a pixel buffer, and that step is skipped entirely for vector output. You get a valid, scannable QR code, just not the one you asked for if you expected a logo in the centre.

Batch behaves differently, and more safely: POST /api/v1/generate/batch rejects a logo combined with format: svg outright, with a 422 and no credit consumed, rather than silently dropping it across up to 25 items. If your integration needs both a logo and vector output, neither endpoint gives you that combination, PNG with a logo, then a separate vectorization step downstream if you genuinely need SVG later, is the only path.

PDF: a rasterized image in a single-page container, not a vector file

PDF output is the one most likely to be picked for the wrong reason. It sounds like the print-ready, resolution-independent choice, PDF is a vector-native format in general, and a lot of design and print software treats a PDF as scalable by default. Qrop's PDF output isn't that: it's the same PNG raster that format: png would produce, embedded as a single image on a single PDF page. Requesting a logo or custom colours works exactly as it does for PNG, since the rasterization step is identical, only the container around the finished image changes.

That means the resolution you request still matters for a PDF the same way it matters for a PNG: pick the target print size and set resolution accordingly before generating, don't rely on the PDF wrapper to make the image scale cleanly afterward. If a print vendor's workflow specifically expects a true vector PDF (no raster content, infinitely scalable), Qrop's PDF output won't satisfy that requirement, SVG is the closer fit there, with the logo caveat above in mind.

Where PDF output genuinely earns its place over PNG is workflow, not image quality: a system that already ingests PDFs (a document generator, an invoicing pipeline, a print queue that expects one file per page) can drop a QR code straight into that pipeline without a separate embed-image-into-PDF step of its own.

Picking a format for the integration, not the code

• Web and app display, email, dashboards: png. Full feature support, and screen contexts rarely need true vector scaling.
• A logo is required, on either a single call or a batch: png. It's the only format where the logo is guaranteed to actually render.
• Print at a size you don't know yet, or content that needs to scale cleanly across many sizes without regenerating: svg, as long as the design doesn't also need a logo baked in.
• Feeding directly into a PDF-based document pipeline (invoices, printable tags, an existing print-queue system): pdf, treating it as a convenient container rather than a true vector upgrade over png.
• Mixed requirements across one print run, some items need a logo and others need vector scaling, for instance, are two different requests with two different format values, not one request trying to do both.

Frequently asked questions

Related guides