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.

What SVG Tiny PS Explicitly Allows

What SVG Tiny PS Explicitly Disallows

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.

Common Reasons a Converted File Still Fails

Design Considerations Beyond Pure Compliance

A file can be perfectly compliant with SVG Tiny PS and still be a poor BIMI logo in practice, because compliance and good design are separate concerns. Since most supporting providers render the logo small — often within a circular crop no larger than a typical avatar — extremely fine detail, thin text, or intricate multi-element compositions tend to become an illegible blur at actual display size, even though the underlying vector file itself remains crisp and technically correct. Design for the smallest realistic rendering size first, then confirm it still looks acceptable at that scale before finalizing, rather than designing at a large canvas and assuming it will simply scale down cleanly — vector scaling preserves sharpness, but it does nothing to prevent visual clutter from becoming illegible at small sizes.

Square Canvas and Circular Crop Considerations

While the specification doesn't mandate an exact aspect ratio, a square (1:1) canvas has become the de facto standard, because most major providers render the logo within either a square or circular frame, and a non-square source image produces unpredictable, provider-dependent cropping that's hard to control for. Design the logo to remain recognizable and well-composed within a circular crop specifically, even if the underlying SVG canvas itself is technically square — this typically means keeping the most important visual elements centered and avoiding critical details near the corners, which get cut off by a circular mask even though they'd be visible in a square one.

Testing Your Logo Before It Goes Live

Beyond structural SVG Tiny PS validation, it's worth testing the visual rendering directly: embed the file in a simple HTML page using an <img> tag (the same rendering method email clients use), view it at multiple sizes down to roughly 32 to 48 pixels square, and check it against both light and dark inbox themes if your logo has a transparent or light background, since some clients now default to dark mode and a logo designed only against a white background can look inconsistent or hard to read there. Use the BIMI Checker to confirm the file is reachable and structurally passes basic SVG validation once it's published, as part of the broader end-to-end BIMI verification.

Tools and Approaches for Different Skill Levels

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.

Color Profile and Rendering Consistency

SVG color values in a BIMI logo should be specified using standard sRGB hex or RGB notation rather than relying on embedded ICC color profiles or CMYK values carried over from print-oriented design workflows, since email client rendering engines are built around standard web color spaces and any embedded profile information is, at best, ignored and at worst a source of unnecessary file complexity that a strict validator may flag as non-essential content. Brand colors originally specified in Pantone or CMYK for print materials should be explicitly converted to their nearest accurate sRGB hex equivalent as a deliberate step in the logo preparation process, documented alongside the brand's other digital asset guidelines, rather than left to an automatic and sometimes inconsistent conversion performed silently by whichever design tool happens to be used for a given export.

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.

Expert Tips for a Clean Compliance Pass

How SVG Tiny PS Compares to Other Restricted Format Profiles

This comparison is useful mainly to correct a specific, recurring misconception: SVG Tiny PS is considerably stricter than typical "email-safe" content restrictions elsewhere in the email ecosystem, precisely because it's rendered in a more trusted, less sandboxed context than a message body itself — a nuance that matters when briefing a design or development team more familiar with general email-safe content guidelines than BIMI's specific requirements.

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.

Maintaining the Logo File Over Time

A compliant SVG logo isn't necessarily a permanent, unchanging asset — brand refreshes happen, and when they do, the BIMI logo needs to be updated alongside every other brand asset rather than quietly left outdated at its original hosted URL. Establish a clear internal process for who is responsible for updating the hosted BIMI logo file whenever a broader brand refresh occurs, since this file sits somewhat outside typical marketing asset workflows (being referenced by a DNS record rather than distributed through normal design asset channels) and is therefore easy to overlook during a rebrand. If a VMC is in place, remember that updating the logo without also updating the certificate creates a mismatch that will likely cause validation failures at the certificate level, meaning any significant logo change should trigger both a new SVG conversion pass and, if pursuing certificate-backed display, a corresponding certificate reissuance reflecting the updated mark.

Frequently Overlooked Technical Details in Hosting

Beyond the SVG file's internal structure, how it's actually served matters for reliable BIMI display. Confirm the hosting server returns an appropriate content type header for SVG files — some default web server or CDN configurations serve .svg files as generic binary data (application/octet-stream) rather than the expected image/svg+xml, which some stricter validators and providers treat as a failure even though the file content itself is entirely valid. Confirm the URL doesn't redirect through an intermediate tracking or CDN layer that could interfere with automated fetching, and confirm there's no caching configuration that might serve a stale version of the file for an extended period after an update, which can create confusing, hard-to-diagnose situations where a corrected file appears to still be failing validation simply because a cache hasn't yet expired.

How This Fits Into the Broader BIMI Setup

The logo file is one of several independent requirements a working BIMI setup depends on, alongside DMARC enforcement and, for most major providers, a Verified Mark Certificate. A perfectly compliant SVG published without DMARC enforcement will still not display anywhere — see BIMI vs DMARC for how that prerequisite works — and a perfectly compliant SVG without a certificate will only display in providers that don't require one. For the complete requirements picture, read BIMI Requirements, and for the certificate process specifically, see Verified Mark Certificate (VMC).

Final Word: Compliance as an Ongoing Design Constraint

Once a brand has gone through the SVG Tiny PS conversion process a first time, the constraint becomes far easier to work with going forward — it's genuinely a one-time learning curve rather than a recurring burden, provided the process and the reasoning behind each restriction is documented somewhere the design team can reference during future updates. Treat the finished, compliant file as a permanent addition to your brand asset library rather than a one-off deliverable produced for a single BIMI launch, and build awareness of the Tiny PS restrictions into your broader brand guidelines documentation so that any future logo refresh accounts for BIMI compatibility from the start, rather than requiring the entire simplification and cleanup process to be repeated from scratch each time the brand identity evolves.

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.