BIMI SVG Files: What Makes a Logo Valid for the Inbox
Most SVG files you meet on the web can contain almost anything: scripts, animations, external images, fonts and filters. A BIMI logo file cannot. The BIMI profile restricts SVG to a small, safe subset so that mailbox providers can render a logo without running code or fetching outside resources. The BIMI SVG Validator checks SVG text that you paste in against those restrictions and reports what it finds. Like the record checker, it works on the text you supply: it does not fetch a file from a URL, and it does not prove that a mailbox provider will accept the logo. Understanding the restricted profile is the key to reading its report, because many findings that look like errors are really the profile doing its job.
How it works
The required pieces are simple to list. A BIMI SVG must have an SVG root element with the usual XML namespace, and it must contain a title element, which gives the logo a text name for accessibility and identification. The artwork itself should be built from basic shapes and paths, using fills and simple styling that the profile permits. The profile also restricts the document size and the overall structure, keeping the file small and predictable. Anything beyond that list deserves a second look. If your exported file contains elements or attributes that the validator flags, the fix is usually to simplify the artwork or to change the export settings in the design tool, not to edit the SVG by hand in ways that might break the drawing.
Where it goes wrong
The riskiest content is anything that reaches outside the file or runs code. Scripts are the clearest example: an SVG that contains JavaScript is not a logo, it is a program, and no inbox should run it. External references are nearly as problematic, because they let the file pull in images, fonts or stylesheets from elsewhere, which breaks the idea of a single self-contained logo and can leak information about the reader. Animations, filters and embedded fonts may also fall outside the profile, even though they are harmless in a browser. A validator that flags these is not being picky; it is enforcing the boundary that makes BIMI logos safe to display in millions of inboxes.
Worked example
Worked example with sample values. Suppose you paste a sample SVG of 24 lines into the validator. It contains one root element, one title element reading Sample Brand Mark, and 12 path elements that draw the mark. It contains no script elements, no external references and no animation elements. Counting the findings gives a useful summary: required pieces present, 2 out of 2, and risky pieces found, 0 out of 3 checked categories. The arithmetic is trivial but the habit is valuable: always count what passed and what failed separately, because a report with one failure and a report with ten failures call for different responses. One failure usually means a single export setting; ten failures usually mean the file was exported with the wrong profile entirely. The sample here is illustrative, not a live validation result.
Mistakes to avoid
Export settings are where most real failures begin. Design tools often export SVG with extra metadata, editor-specific attributes, embedded raster images or font definitions, all of which can trip a strict profile. Before exporting, check whether your tool offers a clean or optimised SVG export, and prefer that over a full-fidelity export. If the logo uses text, convert the text to outlines where the design allows, so the file does not depend on a font being present. If the logo uses a photographic element, remember that BIMI logos are vector artwork: a raster image embedded in an SVG is a warning sign, not a solution. Keep the source artwork, export a fresh copy after each change, and validate the exported file rather than an earlier draft.
Putting it into practice
Treat validation as a loop, not a single test. Paste the exported SVG text, read each finding, and fix the artwork or the export settings that caused it. Re-export and re-validate until the report is clean, and keep the final validated file as the version you publish. Check the logo at small sizes too, since inbox logos are tiny: fine detail that survives validation may still be unreadable at 32 pixels wide. When the file is clean and legible, it is ready to be referenced from the BIMI record, which is a separate check with its own rules.
Related tools and reading: the URL Encoder & Decoder and the Word Counter cover neighbouring checks that pair naturally with this one, and the guide at [/blog/email-deliverability-preflight-checker-guide/] extends the same topic with further background and examples for readers who want to go deeper.
Key points
- Root element present with the correct namespace
- Exactly one title element describing the logo
- No scripts, external references or animations
- Artwork built from permitted shapes and paths
- File re-validated after every export change
In short: A BIMI SVG needs a root element, a title, and a restricted feature set. The validator reads pasted SVG text; it does not fetch a live file. Scripts, external references and risky content are not allowed. Fix the artwork at its source, then re-validate the exported file.
One habit ties all of this together: re-check after every change. A result from the BIMI SVG Validator is only as current as the text it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.