SVG Logo for BIMI: How to Build a Compliant SVG Tiny PS File

Why BIMI Doesn't Just Accept Any Image File

It's a fair question the first time you encounter it: why does an email standard care so specifically about SVG, and why does it further restrict SVG down to a narrow subset instead of accepting any reasonably common image format? The answer comes down to where the logo actually gets rendered. Unlike an image attached inside an email body — which most clients treat cautiously, often blocking it by default until the recipient explicitly allows images — a BIMI logo is rendered directly by the mailbox provider's own trusted interface, in the sender list, before the recipient has made any trust decision about the message at all. That's a meaningfully more privileged rendering context, and it's exactly why BIMI can't simply accept an arbitrary raster or vector file the way an embedded email image can be more loosely handled.

SVG was chosen as the base format because it's vector-based (scaling cleanly to any display density without quality loss, which matters given how many different screen sizes render inbox lists) and because, unlike a raster format, its underlying XML structure can be inspected and restricted in a well-defined, verifiable way. That restriction is SVG Tiny Portable/Secure — commonly abbreviated SVG Tiny PS — a profile derived from the older SVG Tiny 1.2 mobile specification, further locked down specifically for BIMI's use case by stripping out scripting, external references, and any other feature that could turn a supposedly static brand image into something capable of executing code or reaching outside itself once rendered.

A Practical Conversion Process

Starting from an existing brand logo — typically available as AI, EPS, PDF, or a general-purpose SVG export — the practical path to a compliant file usually follows a consistent sequence. First, simplify the artwork itself: reduce excessive path complexity, remove any embedded raster elements like photographic textures or drop-shadow bitmaps, and convert any live text to outlined vector paths so no font dependency remains. Second, export as SVG using a clean, minimal export setting if your design tool offers one, avoiding options that embed extra metadata, editor-specific comments, or unnecessary namespace declarations. Third, open the resulting file in a plain text editor and manually inspect the raw XML for anything resembling a script tag, an external href pointing to an https:// or http:// resource, or animation-related elements like <animate> or <set> — strip any that appear. Fourth, validate the cleaned file against SVG Tiny PS restrictions using a dedicated validator, and iterate if anything fails. Finally, host the finished file at a stable, permanent HTTPS URL and confirm it loads correctly as a plain image before referencing it in your BIMI record's l= tag.

Understanding the XML Structure Under the Hood

For anyone comfortable reading raw markup, opening a BIMI-candidate SVG file in a plain text editor rather than a graphics application is genuinely the fastest way to spot compliance problems, because many of the disallowed constructs are invisible in a visual preview but immediately obvious in the source. A typical problematic export from a general-purpose design tool often carries a block of RDF metadata near the top of the file describing the editing application, version history, and color profile information — none of which affects how the image looks but all of which adds unnecessary weight and, in stricter validators, can itself be flagged as non-conformant content outside the minimal expected structure. Beneath that, look specifically for a <defs> section, since this is where external font references, embedded raster data encoded as base64, and occasionally leftover script hooks tend to hide, having been added automatically by the export process rather than deliberately by the designer. A clean, compliant file is usually dramatically smaller in raw byte size than an unmodified export from mainstream design software — often by a factor of five to ten — precisely because so much of a typical export consists of exactly this kind of non-essential metadata and structure.

Step-by-Step Walkthrough: From Illustrator Export to Compliant File

Since Adobe Illustrator remains one of the most common sources for professional logo artwork, it's worth walking through a concrete example of the conversion process using it as a starting point, understanding the same general principles apply regardless of which design tool originated the artwork. Begin by opening the logo file and using Illustrator's own "Simplify Path" function to reduce anchor point count, particularly on any organic or hand-drawn elements, since fewer anchor points produce a smaller, cleaner underlying file. Next, select all text elements and convert them to outlines (Type menu, "Create Outlines"), which permanently converts live, font-dependent text into pure vector paths with no external font dependency remaining — this step is not optional, since a BIMI logo referencing an external font would violate the no-external-references restriction entirely. Then, before exporting, check the Layers panel for any embedded raster images, texture overlays, or drop shadows rendered as bitmap effects, and either remove them entirely or manually recreate the visual effect using pure vector techniques, since raster content embedded within an otherwise vector file is one of the most common causes of validation failure. When exporting, choose "SVG" format and, in the export dialog, select the most minimal styling option available (typically "Presentation Attributes" rather than "Internal CSS" or "External CSS"), decline to include editing capabilities or responsiveness options if offered, and disable the option to include Illustrator editing data. The resulting file still requires manual inspection afterward, but this export configuration produces a substantially cleaner starting point than the tool's default settings.

Step-by-Step Walkthrough: From Figma Export

Figma has become an increasingly common source for brand assets, especially among newer companies, and its SVG export follows a similar but distinct cleanup path. After selecting the logo frame or group, use Figma's "Flatten" function on any complex vector shapes to simplify overlapping paths into single, cleaner outlines, and separately convert any text layers using "Outline Stroke" or by flattening text into vector shapes, since Figma's default export otherwise references font information that doesn't translate into a font-independent static file. Figma's SVG export panel offers an "Outline text" toggle that should always be enabled for BIMI purposes specifically, alongside minimizing the "Include 'id' attributes" option, since these auto-generated IDs add unnecessary bulk without providing any functional benefit for a static logo use case. As with Illustrator exports, a manual pass through the raw XML afterward remains a necessary final step, since even a carefully configured export can retain small structural quirks a validator will flag.

Handling Multi-Element and Layered Logos

Logos combining a distinct icon or symbol with separate wordmark text — a very common brand composition — deserve specific attention during conversion, since combining multiple originally-separate design elements into a single cohesive SVG file sometimes introduces layering or grouping artifacts that a design tool handles gracefully in its own interface but exports awkwardly into raw SVG structure. Flatten the composition into the minimum necessary number of distinct path and shape elements before export, grouping only where logically necessary (for instance, keeping the icon and wordmark as clearly separated groups if a provider or future use case might need to isolate them), and avoid deeply nested group structures that add unnecessary XML depth without changing the visual output. A logo with an icon-only variant intended for extremely small display contexts, separate from the full icon-plus-wordmark version used elsewhere, should be treated as two entirely separate compliance efforts, since BIMI only supports referencing a single logo file per record and the icon-only variant is almost always the more appropriate choice given how small BIMI logos typically render.

Version Control and Asset Management for the Logo File

Because the BIMI logo file is referenced by a stable URL rather than embedded directly in the DNS record, treating it with the same version control discipline as any other production asset — rather than as a one-off export sitting in an arbitrary folder — pays off considerably over time. Keep the original, editable source file (AI, Figma, or equivalent) alongside the final compliant SVG in a version-controlled location, documenting exactly which export settings and manual cleanup steps were applied, so a future update to the brand mark can follow the same validated process rather than starting the compliance discovery process over from scratch. Organizations with a formal brand asset library should add the compliant BIMI SVG as an explicit, documented asset within that library, distinct from the general-purpose logo files used for other design purposes, precisely because it has structural constraints those other files don't share and shouldn't be casually swapped out by someone unaware of the Tiny PS restrictions.

What to Do If You Can't Achieve Full Compliance In-House

Not every organization has design or development resources familiar with restricted SVG profiles, and that's a reasonable position to be in rather than a blocker that needs to be solved internally at all costs. Freelance vector and icon designers, even those without prior specific BIMI experience, can typically produce a compliant file quickly once given the Tiny PS restrictions as an explicit brief, since the underlying skill — clean, minimal vector artwork — is a standard part of professional icon and logo design work regardless of the specific downstream use case. When briefing an external designer or agency, provide the restrictions list explicitly (no scripts, no external references, no animation, no embedded raster content) rather than assuming general SVG familiarity is sufficient, and request the raw SVG source file for your own review and validation rather than only a rendered preview image, since only the raw file can actually be checked for compliance.

Real-World Use Cases

Accessibility and Fallback Considerations

Because a BIMI logo is displayed automatically by the mailbox provider's own interface rather than embedded in message content the sender controls at send time, traditional email accessibility techniques like alt text don't directly apply to it the way they would to an image inside the message body. That said, it's still worth considering how the logo behaves for recipients using screen readers or other assistive technology, since some mail clients do expose the sender's display name or domain alongside or instead of the visual logo for accessibility purposes — meaning the visual logo itself functions as a supplementary trust signal rather than the primary way any recipient identifies the sender, which is a reasonable design assumption to build around rather than something that needs separate accommodation within the SVG file itself. What does matter directly is sufficient color contrast within the logo design itself, both for general visual clarity and because some inbox themes render against unpredictable background colors depending on light or dark mode settings, making a logo that depends on subtle color distinctions harder to read consistently across different viewing contexts.

Legal and Trademark Alignment of the Logo File

Beyond the purely technical compliance work covered throughout this guide, it's worth flagging a requirement that sits at the intersection of design and legal review: if your organization intends to pursue a Verified Mark Certificate, the exact logo published in your BIMI record needs to match the registered trademark on file precisely, not a close variant, seasonal reskin, or simplified alternate version. This means the SVG conversion and simplification work described above needs to happen in coordination with whoever manages trademark documentation internally, ideally before finalizing the file, rather than as an entirely separate design-only exercise that a legal or brand team only reviews afterward. A logo simplified too aggressively during the SVG conversion process — removing a distinctive design element for the sake of easier compliance or smaller-size legibility — can inadvertently create a mismatch with the registered trademark that later blocks VMC issuance, even though the file itself is a perfectly valid, compliant SVG Tiny PS document. Coordinating design and legal review early avoids discovering this mismatch only after certificate issuance has already begun.

Related Reading

Start with the foundational overview in What Is BIMI?. For the full requirements checklist covering every layer, not just the logo, see BIMI Requirements. For the certificate step that typically follows logo preparation, read Verified Mark Certificate (VMC). To check whether a published logo file is actually reachable and structurally valid right now, use the BIMI Checker.