Why the GARAN-Label is a PNG, not an SVG
A vector version of the GARAN-Label sounds like an upgrade: smaller in theory, infinitely scalable, "more modern". In practice, an SVG guarantee label creates more problems than it solves. Here's why we deliberately generate every GARAN-Label as a PNG.
Short version: an SVG GARAN-Label is larger on disk once you count the required font, breaks its own QR code as soon as a second label appears on the same page, and often fails to display at all in order confirmation emails. A PNG has none of these issues.
Problem 1: the file size adds up
A single GARAN-Label as SVG weighs in at around 300 KB. To render correctly, it also depends on the Inter font, adding roughly another 350 KB if that font isn't already loaded on the page. That's about 650 KB for a single compliance label, before your product photos, theme, and everything else on the page even start loading.
On a product listing with dozens of items, or a shop that hasn't already loaded Inter for its own design, this adds real weight to page load time and Core Web Vitals, for a small label that's meant to be a footnote, not a headline.
Problem 2: multiple labels on one page break the QR code
The GARAN-Label's QR code inside the SVG is built using internal element references (IDs). That's normal practice for SVG graphics, but it only works reliably when the SVG appears once per page. As soon as a second GARAN-Label with the same markup is embedded inline on the same page, browsers can only resolve the first element with a given ID, so every subsequent label silently loses its QR code (or other ID-referenced parts).
This isn't a rare edge case: it happens on any category page, comparison table, or cart view that shows more than one product with a GARAN-Label at the same time.
Problem 3: it has to work in order confirmation emails too
The GARAN-Label doesn't only need to appear on the product page, it also belongs in the order confirmation email. This is where SVG runs into its biggest limitation:
- Many email clients don't render SVG at all. Outlook's rendering engine has no SVG support, and Gmail strips SVG images for security reasons (an SVG can contain embedded JavaScript). Depending on the client, the label simply doesn't show up.
- The same ID collision from Problem 2 applies inside an email as soon as an order contains more than one product with a label.
- Attaching a file instead isn't a real workaround. Platforms like Shopify don't offer a way to generate and attach a custom PDF or file per order to the confirmation email, so you can't simply sidestep the display problem with an attachment.
Our recommendation: PNG
A GARAN-Label is a small, fixed-size compliance label, not artwork that needs to scale to any size, so the main argument for SVG (infinite scalability) doesn't really apply here. A PNG:
- needs no separate webfont, since the text is already rendered into the image,
- has no internal IDs, so any number of labels on one page or in one email render independently and correctly,
- is supported identically by every browser, every major email client, and every PDF or print workflow,
- and is exported at a resolution that stays sharp both on screen and in print.
That's why GARAN-Label.com generates every label as a PNG by default.
Adding the label to your shop? See the Shopify guide →
Frequently asked questions
Can I get my GARAN-Label as an SVG instead of a PNG?
We generate every GARAN-Label as a PNG image by design. In testing, the SVG version caused more problems than it solved (file size, font dependencies, broken QR codes, email compatibility) without any real benefit for a label that's displayed at a fixed size.
Doesn't a PNG lose quality compared to a vector format?
Not in practice. A GARAN-Label is placed at a fixed, fairly small size on a product page, packaging, or invoice; it never needs to scale up to poster size. Our PNGs are exported at a resolution that stays crisp both on screen and in print.
Why does the QR code break with multiple SVG labels on one page?
The SVG markup for the QR code relies on internal element IDs. Browsers only resolve the first element with a given ID on a page, so as soon as a second, third, or further SVG label with the same internal IDs is embedded inline, its QR code (and other ID-referenced parts) silently fails to render. A PNG has no internal IDs, so this problem doesn't exist.
Does this also affect PDF invoices or order confirmation emails?
Yes, in the same way. Multiple inline SVGs on one document share the same ID collisions, and several email clients don't render SVG images at all. A PNG renders identically everywhere: browsers, PDF invoices, and every major email client.