BIMI Logo & SVG Converter
Turn your logo into the exact SVG format BIMI requires, SVG Tiny Portable/Secure. Upload or paste your SVG and we’ll fix the profile, square it, add the required title, and strip anything disallowed. Free, in your browser, nothing uploaded.
Used for the required <title> inside the SVG.
Upload a .svg file, or paste the SVG markup below.
Your BIMI-ready SVG and a compliance checklist appear here once you add a logo.
Next: publish your BIMI record
Host the downloaded SVG at a public HTTPS URL, then build the DNS record that points to it, including the VMC most inboxes require.
Open the BIMI Record GeneratorWant it done in 30 days instead of two years?
Signet is our sister company. They handle the trademark, the DMARC enforcement, and the Verified Mark Certificate end to end — the three things that stall a BIMI project for eighteen months.
Start the clockWhat is a BIMI SVG converter?
BIMI logos can’t be an ordinary SVG. They have to be SVG Tiny Portable/Secure (P/S): a deliberately restricted profile that’s square, carries a specific set of profile attributes and a <title>, and contains no scripts, animation, external references, raster images, or live text. Design tools rarely export in that exact shape, which is why a logo that looks fine everywhere else gets silently rejected for BIMI. This converter rewrites your SVG into the P/S profile, squares the canvas without distorting the art, strips the disallowed parts, and shows a checklist of exactly what changed and what, if anything, you still need to fix. Once you have the file, host it and build the DNS record with the BIMI record generator, then read the guide to making your company logo BIMI-compatible.
Email authentication knowledge base
What is SVG Tiny P/S, and why won't a normal SVG work?
BIMI doesn't accept any SVG. It requires SVG Tiny Portable/Secure, a locked-down profile of SVG Tiny 1.2. The file must set version="1.2" and baseProfile="tiny-ps", contain a <title>, be square, and include no scripts, animation, external references, raster images, or (in strict validators) live text. A logo exported straight from a design tool usually fails several of these. The converter above sets the profile, squares the canvas, adds the title, and strips the disallowed parts, then tells you if anything is left, such as live text. That you have to fix in your design tool.
How do I make my logo BIMI-compatible?
Start from a vector SVG of your logo. Run it through the converter above: it applies the SVG Tiny P/S profile, pads the artwork to a square, guarantees a <title>, and removes scripts, animation, editor metadata, and external references. Download the result, host it at a public HTTPS URL, and reference that URL in your BIMI record's l= tag. If the checklist flags live text, open the logo in your design tool and convert the text to outlines first. That's the one fix a browser can't safely do for you.
Can I convert a PNG or JPG logo into a BIMI SVG here?
No, and no honest tool should claim to in the browser. BIMI needs a true vector SVG, and automatically tracing a pixel image (PNG, JPG) into clean vector paths produces a bloated, distorted result that fails validation. Export an SVG from the original vector artwork instead: in Illustrator, Figma, or Inkscape, and run that through the converter. If you only have a raster logo, a designer will need to recreate it as a vector first.
Why does BIMI reject the text in my logo?
SVG Tiny P/S disallows live <text> and <tspan> elements, because they depend on fonts the receiver may not have. Your logo has to render identically everywhere, so any lettering must be converted to vector outlines (paths). In your design tool this is usually 'Convert to outlines', 'Outline stroke', or 'Object to path'. The converter flags remaining text as a blocker rather than deleting it, so you don't lose the wordmark.
Does my BIMI logo have to be square?
Yes: BIMI logos are displayed in a circle or rounded square, so the SVG must be 1:1 with the artwork centred. If your logo isn't square, the converter pads the shorter side with even margin so it renders correctly without stretching. A wide wordmark technically passes but will look tiny inside the avatar; a square mark or monogram works best.
How big can a BIMI SVG file be?
The BIMI Group recommends keeping the SVG under 32 KB. Most simple logos are well under that once editor metadata is stripped, which the converter does automatically. If you're over the limit, simplify complex paths, reduce coordinate precision, or flatten unnecessary groups. The converter shows the final file size so you know where you stand.
I have the SVG. How do I create the BIMI record?
Once your converted SVG is hosted at a public HTTPS URL, use the BIMI record generator to build the DNS TXT record that points to it (and to your VMC). Publish that record at default._bimi.yourdomain.com, and confirm your domain already has DMARC at enforcement. BIMI won't display without it.
A BIMI-ready logo is only half of it. BIMI also requires a DMARC policy at enforcement. Here are the DMARC tags involved.
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.