A vector logo is a source file, not a delivery format. Almost every logo problem a company runs into traces back to treating one file as if it were all of them: the SVG that will not take a color from the page, the favicon that never appears in search results, the print file that arrived with the transparency baked in and cannot be undone.
None of this is a matter of taste. The behaviors are specified, the icon requirements are published, and one of them changed recently enough that most brand guidelines still carry the old rule.
The same SVG behaves differently depending on how you place it
There are three ways to put a vector logo on a page and they are not interchangeable. The difference is documented as a security boundary, not a quirk.
When an SVG is used as an image, the browser restricts it. Documented limitations: “JavaScript is disabled”, “external resources (e.g., images, stylesheets) cannot be loaded, though they can be used if inlined through data: URLs”, “:visited-link styles aren’t rendered”, and “platform-native widget styling (based on OS theme) is disabled.”
Which is why your CSS cannot recolor it. An SVG loaded through an image element or a CSS background is an isolated document. The page’s stylesheet never reaches inside it.
And the boundary is stated explicitly. “The above restrictions are specific to image contexts; they don’t apply when SVG content is viewed directly, or when it’s embedded as a document via the <iframe>, <object>, or <embed> elements.”
Inline SVG is the opposite trade. Its markup lives in the document, so page CSS applies, currentColor works, and a single file can follow a theme. The cost is that the markup ships with every page response rather than being cached once as a separate file, which is ordinary HTTP behavior rather than an SVG rule.
Accessibility also splits along this line. With an image element, “the alt attribute provides alternative text making the image accessible”. But “inline SVG does not support the alt attribute.” Instead the source is exposed to the accessibility tree, and a <title> element supplies the accessible name.
With two placement rules worth writing down. The <title> “should be the first element after the <svg> opening tag”, role="img" “ensures assistive technologies handle the SVG as an image”, and if aria-describedby is present “it will take precedence over <desc>.”
The choice is not stylistic. It decides whether CSS reaches the logo, how it is described to assistive technology, and how it caches. Source : MDN Web Docs, SVG as an image and SVG in HTML (2026)
The favicon rules changed, and most guidelines still carry the old ones
This is the one specification worth rechecking, because the current requirement contradicts what was published a few years ago.
The current requirement. “Your favicon must be a square (1:1 aspect ratio) that’s at least 8x8px. While the minimum size requirement is 8x8px, we recommend using a favicon that’s larger than 48x48px so that it looks good on various surfaces.”
The former requirement, now superseded. “Your favicon must be a multiple of 48px square”, with an explicit warning: “Don’t provide a 16x16px favicon.” If your brand guidelines say multiple of 48, they are quoting a rule that no longer applies.
The format list, which is the part that catches people. “Google Search supports the following favicon file formats: BMP, GIF, ICO, PNG, JPEG, PPM, and TIFF.” SVG is not on that list. Browsers accept SVG favicons; search results do not. Ship a raster file alongside it.
Three constraints that break favicons silently. “Google Search only supports one favicon per site, where a site is defined by the hostname.” Googlebot-Image must be able to crawl the file and Googlebot must be able to crawl the home page. And “the favicon URL must be stable”, so a build system that hashes the filename on every deploy is working against you.
The markup detail almost nobody knows. The HTML specification states that “the sizes keywords represent icon sizes in raw pixels (as opposed to CSS pixels)”, that the keyword any “represents that the resource contains a scalable icon”, and that declared sizes “must not represent icon sizes that are not actually available in the linked resource.” Declaring sizes you did not ship is worse than declaring none.
And for installable web apps, a separate minimum. “For Chromium, you must provide at least a 192x192 pixel icon and a 512x512 pixel icon.” Scalable icons are supported there but “stay in the state they were in at install time”, so “always specify a rasterized icon as a fallback.”
The raster format most logos ship in has documented limits that decide where it can and cannot go.
Transparency is optional, not implied. The specification is explicit: “if the alpha channel is not present, all pixels are fully opaque.” A logo exported without alpha carries a white box wherever the background is not white.
And it is a screen format by construction. The specification supports “indexed-color, greyscale, and truecolor images … plus an optional alpha channel”, with four documented ways to declare an RGB color space. It has no process color model, and its own guidance for extensions warns against redefining channels to mean something else.
Which is why print goes through a different file. In PDF, an output intent “describes the final destination device you’ll use to reproduce the color”, and depending on the standard it either describes the working process color space or is used “to dynamically convert any objects with color-managed color to the color space of the ICC profile in the output intent.”
So the correct answer to a printer asking for the logo is not the web file. It is a vector PDF with the intended output condition, or whatever the printer specifies.
One thing about resolution worth being blunt on. A raster logo has a fixed pixel count. Enlarging it does not add detail. Every size a raster logo will be used at has to be exported at that size, which is the entire argument for keeping the vector source.
Two operations in the delivery pipeline are permanent, and both usually happen without anyone deciding to do them.
Flattening transparency. “Flattening divides transparent artwork into vector-based areas and rasterized areas”, and it “may be necessary when you print or when you save or export to other formats that don’t support transparency.”
And the sentence to remember. “Transparency flattening cannot be undone after the file is saved.”
Which formats avoid it. “To retain transparency without flattening when you create PDF files, save your file as Adobe PDF 1.4 (Acrobat 5.0) or later.” Legacy formats, including older EPS and PDF 1.3, flatten on save.
The EPS behavior that explains a lot of mysterious breakage. An EPS saved from a current version of the application “contains both native Illustrator data and EPS data. When you reopen the file in Illustrator, the native (unflattened) data is read. When you place the file into another application, the EPS (flattened) data is read.” The file looks fine to the designer who made it and different to everyone else.
Outlining type is the second permanent step. Converting text to outlines “discards all type glyph information”, which is exactly why it is the right way to hand a logo over, and exactly why the editable original must never be the only copy you keep.
Five checks, none of which need design software, all of which catch a defect that is expensive later.
Open the vector file in a text editor. An SVG is markup. If it opens and you can read shape data, it is genuine vector. If it contains a single embedded image payload, somebody exported a raster file with a vector extension.
Look for live type in the master, and no live type in the handover file. The master must still be editable, and the handover file must not depend on a font the recipient may not license.
Put the logo on a colored background. Missing transparency is invisible against white and obvious against anything else, because without an alpha channel “all pixels are fully opaque.”
Check the favicon against the current rule, not the old one. Square, above 48 pixels, in an accepted raster format, at a URL that will not change on the next deploy.
And ask which file is the source. If the answer is an outlined, flattened export, the set has no source, and every future change starts from a redraw.
A logo handover is complete when you can regenerate everything from what you hold. Five things achieve that.
The editable master, unflattened, with live type. This is the only file that cannot be recreated from the others. Everything below is derived from it.
An outlined vector for handover. The version you send to printers, partners and suppliers, which carries no font dependency and no licensing question.
Web exports, per placement. An SVG for inline use where the logo needs to follow a theme, and a separate one for image-element use where it does not. They can be the same drawing exported twice with different assumptions.
A favicon set that satisfies both audiences. A raster file in an accepted format at a size above 48 pixels for search results, plus the platform icons: 192 and 512 pixel application icons, and the touch icons at the sizes your platforms document.
And the specification of what each file is for. A one-page note listing which file goes where. Without it the whole set collapses back into whichever file somebody found first, which is how a flattened JPEG ends up on a printed banner. The set is only ever as good as the drawing behind it, and a mark built to hold at favicon size and on a printed banner alike is what turns the exports into a formality.
Because of how it is embedded. Browsers restrict SVG used as an image: scripting is disabled and external resources cannot load. Page CSS can only style an SVG written inline in the document.
Can I use an SVG favicon?
Browsers support it, but Google's search results do not. Google's accepted favicon formats are BMP, GIF, ICO, PNG, JPEG, PPM and TIFF. SVG is not on that list, so ship a raster favicon as well.
What favicon size does Google require now?
Square, at least 8x8 pixels, with larger than 48x48 recommended. The older rule requiring a multiple of 48px, and warning against 16x16, has been replaced.
Is flattening a logo reversible?
No. Adobe states that transparency flattening cannot be undone after the file is saved. Keep the unflattened source and treat flattened exports as disposable output.