What are the recommended SVG dimensions for BIMI and how should I create the SVG?
The practical answer is: create a square BIMI SVG on a 520 by 520 pixel canvas, keep the logo centered, use a real vector source, and export it as SVG Tiny 1.2 before editing it to the BIMI SVG P/S profile. A 400 by 400 square is also common, and Google states a minimum height and width of 96 pixels for Gmail BIMI images, but I hand design and DevOps a 520 by 520 working target because it gives everyone a clear review size without changing the vector nature of the file.
The pixel dimensions are not the thing that makes an SVG sharp. A proper SVG is vector instructions, so it should scale cleanly. If someone zooms into the file and it looks blurry, the usual cause is a PNG or JPG embedded inside an SVG container, a logo that was auto-traced badly, or a preview app that rasterized the file for display.
Do not wrap a PNG
A file can end in .svg and still fail the BIMI intent. If the SVG contains an embedded bitmap, the logo can blur when scaled and can fail BIMI validation. Ask design for the original vector logo, usually from an AI, EPS, PDF, or source brand file, then export from that source.
I treat 520 by 520 as the production handoff size, not as a hard BIMI law. The hard parts are the SVG profile, the square canvas, the centered mark, the solid background, the small file size, and the DMARC enforcement behind the sending domain.
Recommended dimensions
Use a square artboard and set both the SVG width and height as absolute pixel values. My default is 520 by 520 because it is large enough for brand review, easy to reason about, and still compact when the artwork is real vector. The BIMI SVG guide focuses on square layout, centering, SVG P/S structure, and a 32 KB maximum file size rather than a single universal pixel dimension.
|
|
|
|---|---|---|
Canvas | 520x520 | Good review size |
Minimum | 96x96 | Gmail minimum |
Aspect | Square | Predictable crop |
File | 32 KB max | BIMI limit |
Profile | Tiny P/S | BIMI format |
BIMI SVG size recommendations
Google's Google BIMI steps add Gmail-specific details: use absolute pixels, avoid percentage sizing, keep the logo centered in a square, use a solid background, keep the file at 32 KB or smaller, include a description element for accessibility, and avoid bitmaps, linked files, live text, and grouped objects.
BIMI SVG dimension targets
A practical way to classify the square canvas size before export.
Good working target
520x520
Clear for brand review and simple for DevOps handoff.
Acceptable common target
400x400
Often enough when the source artwork is real vector.
Too small for source raster work
60x60
Avoid converting tiny bitmap logos into SVG files.
The chart matters only if the starting artwork is not already vector. If design has a true vector logo, a 96, 400, 520, or 6000 unit SVG can still render sharply because the shapes are mathematical paths. If the starting point is a 60 by 60 PNG, making the SVG canvas 520 by 520 only creates a larger container for the same low-detail raster image.
Why a BIMI SVG gets blurry
A clean BIMI SVG should not be blurry at normal display sizes. When I see blur, I look for raster content first. Open the SVG in a text editor and search for image, base64, .png, or .jpg. Those are signs the file contains or references bitmap artwork.
Good source
- Vector paths: The logo is built from paths, fills, and shapes rather than pixels.
- Sharp scaling: The mark stays clean when viewed larger than the inbox display size.
- Small output: The file stays under 32 KB without heavy embedded data.
Bad source
- Wrapped bitmap: The SVG file contains a PNG or JPG inside the file.
- Messy trace: Automatic tracing creates rough edges and too many points.
- Wrong preview: A viewer renders a low-quality preview even though the file is usable.
There is a useful distinction here: BIMI does not reward a huge pixel canvas, but brand teams do need enough working space to review the logo. That is why 520 by 520 is a sensible internal target. It gives design a concrete canvas while keeping DevOps focused on compliance, file size, hosting, DNS, and authentication.
A BIMI SVG blur checklist comparing vector paths with wrapped bitmap artwork.
The SVG structure to create
For BIMI, the file needs to be SVG Tiny Portable/Secure, often written as SVG P/S. In practice, many teams export SVG Tiny 1.2 from a design app, then manually edit the root attributes and metadata because general design tools do not normally export a perfect BIMI-ready profile.
- Root profile: Use version set to 1.2 and baseProfile set to tiny-ps.
- Square viewBox: Use a square viewBox such as 0 0 520 520.
- Absolute size: Use pixel values for width and height, not percentages.
- Metadata: Include a title element and add a desc element for accessibility.
- No extras: Remove scripts, animation, external references, bitmaps, and root x or y attributes.
Minimal BIMI SVG shapexml
<?xml version='1.0' encoding='UTF-8'?> <svg version='1.2' baseProfile='tiny-ps' xmlns='http://www.w3.org/2000/svg' viewBox='0 0 520 520' width='520' height='520' overflow='visible'> <title>Example Brand</title> <desc>Example Brand BIMI logo.</desc> <rect width='520' height='520' fill='#ffffff'/> <path d='M140 140h240v240H140z' fill='#111111'/> </svg>
The example is intentionally simple. Real brand artwork will have more path data, but the structure should stay boring. I prefer boring here because a minimal file is easier to validate, easier to host, and less likely to contain something a mailbox provider rejects.
If you need the full compliance checklist, keep a separate reference for BIMI SVG requirements and run the final file through validation before touching DNS.
A practical creation workflow
The smoothest path is to keep design responsible for the logo geometry and DevOps responsible for hosting, DNS, and monitoring. When those roles blur, teams end up with screenshots pasted into SVG files, overfilled artboards, and DNS records pointing at files that later fail validation.
- Start with source: Use the original vector logo, not an image pulled from a website header.
- Set the canvas: Create a 520 by 520 square artboard with a solid background.
- Center the mark: Leave enough padding for circular and rounded-square inbox treatments.
- Outline text: Convert word marks to paths so the file does not depend on fonts.
- Export Tiny 1.2: Export SVG Tiny 1.2, then edit the root profile to tiny-ps.
- Clean the file: Remove unsupported attributes, embedded images, scripts, and linked assets.
Adobe Illustrator SVG export settings for a square BIMI logo.
A good visual target is a mark that occupies about 70 to 80 percent of the square's width, with the rest left as breathing room for provider-specific crops. If the logo is a word mark, test the small display size before publishing. Thin letters and long horizontal marks often need a special BIMI treatment, even if the trademark team prefers the full corporate lockup.
When the only source is a PDF
If your company has a clean vector logo inside a brand PDF, design can often open that PDF in a vector editor, extract the logo, and export a proper SVG. That is a rescue path, not a shortcut for DevOps to convert any PDF screenshot into BIMI.
DMARC and BIMI readiness
A perfect SVG does not make BIMI work by itself. The sending domain also needs DMARC in enforcement. That usually means p=quarantine or p=reject with reporting in place so you know which legitimate sources are passing SPF or DKIM with a matching domain before you enforce.
For most teams, Suped is the strongest practical choice for the DMARC layer behind BIMI because Suped's DMARC monitoring turns aggregate reports into source-level fixes, real-time alerts, policy staging, SPF and DKIM monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, and blocklist monitoring in one workflow. That matters because BIMI work often stalls on authentication gaps, not on the SVG file.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Before publishing the BIMI DNS record, check the domain's authentication posture. A domain health check is useful when you want one pass across DMARC, SPF, and DKIM. If you only need to verify the DMARC TXT record and policy tags, use a DMARC checker before moving to BIMI.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
This is also where I separate two tracks: the marketing track owns the logo and certificate conversation, while the authentication track owns DMARC domain matching and enforcement. A BIMI project needs both, but those tracks fail in different ways. The logo can be beautiful and invalid, while the DNS can be correct and still blocked by a relaxed DMARC rollout.
Validation before publishing
Validate the SVG before you publish the BIMI record. I do this before DNS because a failed SVG is faster to fix in design handoff than after everyone has cached a BIMI TXT record and started checking inboxes.
BIMI SVG validation flow from source vector to DNS publishing.
My validation checklist is short: open the file in a text editor, confirm the root profile, confirm the square canvas, search for embedded image content, confirm title and description metadata, check the file size, then validate the final hosted URL. For the wider implementation path, use a separate checklist for BIMI setup steps so the logo file does not get reviewed in isolation.
What good looks like
- Sharp preview: The logo stays crisp when zoomed because it is built from paths.
- Small file: The SVG is under 32 KB without embedded image data.
- Stable crop: The mark remains readable inside a circle or rounded square.
- Clean root: The SVG has the right BIMI profile and no unsupported root attributes.
After validation, host the SVG over HTTPS at a stable URL. Keep the URL boring and permanent. If the logo changes later, replace the file intentionally and revalidate it rather than uploading a new file with a rushed export.
Views from the trenches
Best practices
Start with the source vector file, then export a square SVG Tiny 1.2 file for BIMI.
Use a 520 by 520 artboard so design and DevOps review the same square canvas together.
Keep the logo centered with padding because mailbox providers crop logos differently.
Common pitfalls
Wrapping a PNG inside an SVG passes a filename check but fails the real BIMI goal.
Oversized marks look fine in one inbox, then lose edges when shown inside a circle.
Transparent backgrounds create inconsistent logo tiles across mailbox provider apps.
Expert tips
Check the root SVG attributes manually before asking DNS or DevOps teams to publish.
Treat blur as a warning that the logo was rasterized or exported from the wrong file.
Validate DMARC enforcement before spending time tuning the final BIMI logo artwork.
Marketer from Email Geeks says a true SVG should not blur when scaled, so blur usually means the file contains raster artwork or was exported from the wrong source.
2020-03-20 - Email Geeks
Marketer from Email Geeks says 520 by 520 is a practical working size because it gives brand teams a clear canvas without pretending pixels make vectors sharper.
2020-03-20 - Email Geeks
What I would ship
I would ship a 520 by 520 SVG Tiny P/S file made from the original vector logo, with a centered mark, a solid background, absolute pixel dimensions, a square viewBox, title and description metadata, no embedded bitmap, no scripts, no external references, and a file size under 32 KB.
I would also make the design team own the visual source file and make the email authentication owner validate DMARC before publishing BIMI. That split keeps the logo quality conversation separate from the domain authentication conversation, which is where many BIMI launches slow down.
The important correction is simple: SVG dimensions are a review and compatibility choice, not the cure for blur. Blur means the source or export process needs fixing. Start with a true vector, use 520 by 520 for the working canvas, then validate the BIMI-specific structure before DNS goes live.
