Determine what conversion actually produced
Raster-to-SVG conversion describes several very different operations. One tool may put a PNG inside an SVG wrapper. Another traces pixels into thousands of paths. A designer may instead reconstruct the mark using a small number of deliberate vector shapes. All three outputs can carry the same extension and look similar on a large screen, yet they do not offer the same structural suitability, visual fidelity or maintainability for BIMI.
Start by asking for the converter's output and its provenance, not a claim that conversion succeeded. Identify the source image, its rights owner, the transformation used and the resulting file. This article describes proposed review steps; it does not provide an inspected candidate or executed validator result. BIMI draft work must not be presented as an established IETF standard, and unavailable draft text has not been used as normative evidence here.
A wrapper does not turn pixels into vector geometry
BIMI Group troubleshooting explicitly calls out raster images placed inside SVG as a compliance problem and recommends vectorization or tracing to produce vector paths. Its supported-feature discussion excludes embedded images, scripting, animation and unsupported effects. Changing the extension or the root profile attribute cannot change a bitmap dependency into path geometry. The content must be inspected to learn what actually draws the logo. BIMI Group SVG issues
Inspect for image elements, embedded image data, external image references and effects that the export retained. An external dependency can be hidden behind an apparently portable document. A data-encoded bitmap may make the file self-contained but still leave the embedded-image problem unresolved. Do not remove an image element blindly: if it supplies the entire visible mark, deletion creates an empty or incomplete asset rather than a corrected logo.
Tracing creates new design decisions
Tracing is not a lossless recovery of the original vector master. It estimates contours from pixel boundaries, including antialiasing, compression artifacts and shadows. A small source image can produce lumpy edges or close narrow gaps. The appropriate next step may be to obtain the original artwork from the brand team rather than repeatedly changing converter settings. Record this as a design dependency, not a DNS or mail configuration failure.
BIMI Group recommends simplifying paths, reducing node counts and limiting complex colors and gradients when preparing suitable graphics. Apply these techniques with visual review rather than maximizing compression at any cost. Compare letter shapes, line widths and internal spacing against the approved mark. If simplification changes the meaning or identity of the logo, stop and ask the brand owner to choose an acceptable representation. Simplification guidance
Profile declarations are necessary metadata, not proof
The creation guidance specifies version 1.2, baseProfile tiny-ps and a title. It also identifies prohibited references, active content and root x or y attributes. Treat each as a separate review item. A generic SVG exporter can include unsupported material even when an operator manually changes the declared profile afterward. Conversely, a visual preview that looks correct does not show whether all references and attributes satisfy the intended profile. BIMI Group creation guidance
Keep conversion, structural validation and brand approval as three different states. Conversion records what happened to the input. Structural validation reports what a particular checker found in a particular output. Brand approval confirms that the reviewed depiction is acceptable to its owner. None proves that the public endpoint later serves those exact bytes, or that a receiving mailbox will display the indicator.
Test the receiver overlay separately
Google's Gmail documentation requires SVG width and height of at least 96 pixels using absolute values. Percentage dimensions do not meet that stated requirement. Its centered square, solid background, description element and 32 KB guidance are recommendations. A traced file can therefore fail a receiver-specific requirement even after the embedded bitmap has been removed. Preserve receiver names and source dates beside each condition. Google SVG guidance
Do not use an arbitrary optimizer preset as the final authority. An optimizer can remove metadata or change geometry that another review depends on. Archive the pre-optimization and post-optimization files, compare their structure and appearance, and rerun the chosen checks on the final candidate. When a tool reports a size ceiling, distinguish that tool's configured limit from a published recommendation or receiver requirement. This avoids turning a local warning into an invented universal rule.
Original conversion review worksheet
Use the following proposed record to decide whether to accept, revise or replace the conversion. Leave fields empty or explicitly pending until evidence exists. This worksheet has not been completed against a real logo.
- Input provenance: approved owner, original format, dimensions and source-artwork availability.
- Transformation: wrapper, trace or manual reconstruction; application version and relevant settings.
- Embedded content: image elements, encoded raster data and external references found or unresolved.
- Geometry: path complexity, small gaps, letterform fidelity and any intentional design changes.
- Profile: version, baseProfile, title, root attributes and prohibited elements.
- Receiver conditions: absolute dimensions, required minimums and adopted presentation recommendations.
- Review evidence: candidate digest, validator output and named design approver.
- Delivery dependency: issuer submission version, proposed hosting location and outstanding public fetch.
A rejected conversion should produce an actionable request. “Obtain the approved vector master” is more useful than “make the SVG pass.” Where tracing is unavoidable, specify which visual features must be preserved and which simplifications the owner has approved. Avoid sending unreleased artwork to a public conversion service without permission; a local preparation workflow may be more appropriate when the design is confidential.
Fictional example: three exports from one badge
Fictional Mossfield Books has only a low-resolution badge on hand. Candidate A embeds that PNG inside SVG. Candidate B traces it into many irregular paths. Candidate C is a proposed reconstruction from the publisher's original design file. These are invented descriptions, not inspected files. Candidate A has not solved the embedded-image issue. Candidate B might eliminate the bitmap but still requires structural and visual review. Candidate C is promising only if the approved source can actually be obtained.
The proposed decision is to pause certificate submission until the artwork owner supplies the master or explicitly approves a reconstruction. The team would retain each candidate's digest and findings rather than overwrite the files under one name. A preview screenshot alone would not establish which artifact was reviewed. The example ends at a decision plan; no conversion, validation, certificate application or hosting change was performed.
Keep the evidence gap visible
For Gmail, Google documents a certificate-backed PEM workflow rather than support for a standalone SVG alone. A successful conversion therefore completes at most one part of the overall dependency chain. The accepted candidate must remain consistent with issuer review and the deployed certificate material, while the public endpoint and actual receiver experience need their own evidence. Google certificate workflow
The required candidate asset, validator findings and public HTTPS fetch with content and certificate evidence remain open. Human SME, source applicability, production route, visual accessibility and owner-release gates are also open. This article explains how to distinguish a plausible conversion from an evidenced asset; it does not certify any logo, converter or deployment as compliant.