What Your Developer Actually Needs From Your Logo

There is a conversation that happens on every project, in roughly this form.

"Can you send me the logo?" — Sure, here. "Do you have it as an SVG?" — What's an SVG? "Any version without the white box?" — It doesn't have a white box. "It does on a dark background." — …

It is nobody's fault. The person sending the logo has the file they were given. The person receiving it needs four files that nobody mentioned existed. Here is the spec, written from the receiving end, so the whole exchange can happen once.

The one-paragraph version

Send five files: an SVG, a transparent PNG at roughly 500px wide, a white transparent PNG at the same size, a square icon-only PNG at 512px, and a 1200×630 image for link previews. That covers essentially every request a front-end will make. Everything below is why.

Why the SVG matters more than anything else

An SVG describes your logo as shapes and coordinates rather than as a grid of pixels. Two consequences follow, and they are the whole reason developers ask for it first.

It is resolution-independent. The same file is crisp in a 24-pixel nav bar and on a 4-metre banner. There is no such thing as "the 2× version" because there is no fixed size to double.

And it is usually very small — a typical logo is 2–8 KB, against several hundred KB for a decent PNG of the same mark. On a page where the logo loads before anything else, that difference is directly visible as how fast your site feels.

"It has a white box on dark backgrounds"

This is the single most common handoff bug, and it is worth understanding rather than just reporting.

A PNG can store transparency; a JPG cannot. When a logo is exported as a JPG — or exported as a PNG after being flattened onto a white canvas — the transparent area is filled with white pixels. On a white page you cannot see it. On a dark header it is an obvious rectangle.

The related, subtler version is the fringe: a thin light halo around the edges of an otherwise transparent logo. That happens when the mark was anti-aliased against white before the background was removed, so the edge pixels are genuinely part-white. It is a real defect in the file, not a rendering artefact, and it needs re-cutting from a clean source rather than working around.

The fix on the sending side is to export a transparent PNG from the master. The transparent logo tool does it in one step if all you have is a flat file.

The dark-mode variant

Your site has a dark footer. Or a dark theme. Or a dark hero section. Your full-colour logo, designed against white, either disappears into it or sits there looking muddy.

Developers can invert an image in CSS, and the result is almost always wrong: filter: invert(1) turns your navy logo bright yellow, not white. What they need is an actual white version of the mark, supplied as a file, and then it is one line to swap between them.

Producing it takes a couple of clicks in the logo styler. Not producing it means either a compromise on your dark sections or a hack in the CSS that someone will have to explain later.

Sizes: 1× and 2×, or just the SVG

If you are sending raster files, the developer needs to know how wide the logo will be displayed, and then they want it at twice that. A logo rendered 150 pixels wide needs a 300-pixel file to look sharp on a retina screen; supplied at exactly 150 it looks slightly soft on most modern devices.

What they do not want is your 4 MB, 4000-pixel master dropped into the header. It will be scaled down by the browser, it will look no better than the 300-pixel version, and it will make the page slower for everyone.

The favicon, and why one file is not enough

A favicon request looks trivial and is not, for one reason: the file that works is almost never a shrunk version of your logo. At 32 pixels a wordmark is unreadable. What the tab needs is your icon alone, or a single letter, on a shape that survives being tiny.

The sizes are 32 (tab), 180 (iOS home screen), 192 (Android), and optionally 512 and 16. Render them all from the master rather than from each other — a 32 downscaled from a 64 that was downscaled from a 500 is noticeably mushier than a 32 rendered directly. A favicon generator does the whole set at once.

The OG image, which is not a logo at all

og:image is what renders when your link is pasted into Slack, LinkedIn, X or iMessage. Without it, the link shows as a blank rectangle.

It is 1200 × 630, it must be PNG or JPG (SVG will not render), and the important content belongs in the middle because different platforms crop the edges differently. Text should be large or absent — a preview card is displayed small, and body-copy-sized type is illegible at that scale.

The mistake worth naming: an OG image is not your logo on a white square. It is a card — usually the mark, the product name, and a short line of what you do, laid out to be readable at thumbnail size.

Formats, briefly

PNG for anything with transparency. JPG never for logos — it is lossy, and the compression artefacts cluster exactly around hard edges and text, which is all a logo is. WebP is smaller than PNG at equal quality and supported everywhere that matters now; it is a reasonable default for the web copy, and converting is one step. SVG wherever the mark is drawn rather than photographed.

Developers occasionally ask for a base64 data URI — the image encoded as a string, inlined directly in the CSS or HTML. It removes a network request, which is worth it for a tiny icon in the critical path. It is worth it much less often than people think: the encoding is about a third larger than the binary, it cannot be cached separately, and inlining anything substantial makes the page slower rather than faster. Producing one is easy; deciding it is a good idea is the harder part.

The colours

Send hex values, not a screenshot to sample from. Sampling a colour off a rendered image is unreliable in a specific way: on an anti-aliased edge, the pixel is a blend of your mark and whatever was behind it, so the developer ends up with a plausible-looking hex that appears nowhere in your brand.

If you do not have the values written down, upload the logo to a colour picker, which reads the actual pixel values out of the file, and then write them down. That list is the beginning of a style guide, which you will want eventually anyway.

The handoff, as a message you can paste

Here are the logo files.

• logo.svg — use this wherever you can
• logo-transparent.png — 1000px wide, for anywhere SVG doesn't work
• logo-white-transparent.png — same, for dark backgrounds
• logo-icon-512.png — square, icon only, for the favicon set and app icons
• og-image.png — 1200×630, for link previews

Brand colours: #1B4DB1 primary, #0E2A63 dark, #F5F7FA background.

That message ends the thread. If you can't produce one of those files from what you have, the developer-facing overview covers how to make each one, and the full pre-launch checklist covers the files this list leaves out.