Explain the rule that failed
A BIMI SVG validator should identify the candidate asset, the rule set it applies and the exact failed requirement. A message such as invalid logo is not enough for a designer or operator to correct the asset safely. The validator should distinguish malformed XML, unsupported SVG structure, profile-specific restrictions, receiver recommendations and visual concerns. Those categories can overlap, but they are not interchangeable and should not be presented as one undifferentiated error.
BIMI Group's SVG guidance describes SVG Portable/Secure as a stricter profile of SVG Tiny 1.2. Its retained page dates to 2020 and was captured for this manuscript's source collection on November 8, 2026. This is practical group guidance, not a claim that the referenced BIMI profile draft is an Internet Standard. No validator was executed here.
Identify the exact bytes under review
Record the candidate filename, byte length, content hash, source or export method and observation time. If the asset came from a URL, preserve the retrieved bytes rather than assuming they match a local design file with the same name. A later upload or cache change can mean the hosted asset differs from the file a designer reviewed. The report should make that distinction visible before presenting findings.
Do not execute scripts or follow external references simply to inspect an untrusted SVG. A defensive validator should parse and analyze the asset within its approved safe environment. This article does not prescribe a particular parser implementation or claim that a named tool provides that protection. It defines a requirement to be verified before the validator is trusted with actual assets.
Separate basic syntax from the BIMI profile
A file can be valid XML and valid under a broad SVG model while still failing the intended BIMI profile. The group guidance identifies required values such as version 1.2 and baseProfile tiny-ps, and requires a title element. It also explains restrictions on external references, scripts, animation and root-level x or y attributes. A validator should report the exact element or attribute involved and the source rule, not just note that a browser can render the file.
Changing the filename extension to svg or wrapping a bitmap in an SVG container does not establish profile compliance. BIMI Group's SVG troubleshooting guidance discusses embedded raster imagery and other common problems. The report should explain the structural issue and direct the designer toward an approved vector source or export correction without claiming that any automated conversion preserves the intended brand artwork.
Preserve requirement strength and receiver scope
The group guidance recommends keeping the asset small and not exceeding 32 kilobytes; it also recommends a description element for accessibility rather than making that element universally required in the cited guidance. A validator should distinguish required failures from recommendations. Turning every recommendation into a fatal error can mislead users just as much as silently accepting a prohibited element.
Google's BIMI setup documentation adds receiver-specific requirements and recommendations, including a minimum height and width of 96 pixels in its documented logo guidance. Those are Google-scoped rules. The validator should identify whether it is checking the group profile, Google's eligibility guidance or both, and should not label every receiver-specific condition as a universal SVG requirement.
Make findings actionable without silently changing meaning
For each finding, record the rule identifier or source section, severity, location in the asset, observed value, expected condition and a proposed remediation. A remediation should explain the intended change rather than silently editing the file and calling it fixed. Removing a reference, converting text to paths or changing geometry can alter visual meaning and needs an appropriate design review.
If the tool offers automatic repair, treat the repaired asset as a new candidate with its own hash and findings. Preserve the original and show the exact changes. The repair should not add a legal claim about logo ownership or certificate eligibility. No automatic repair, image generation or asset transformation was performed for this manuscript, and no purported clean validator output is supplied.
Keep appearance and accessibility as separate reviews
A structurally valid file can still be difficult to recognize in a small avatar, have poor contrast or include an unhelpful title. A visual review should assess the intended display context, while an accessibility review should examine the relevant textual description and presentation. Neither can be inferred solely from a schema or profile pass. The tool report should mark these reviews open until actual evidence exists.
Do not promise that a particular receiver will render the file exactly like a local preview. Receiver display behavior, cropping and eligibility can differ. A preview is evidence of that preview environment only. The final acceptance record should identify which renderer or client was observed and avoid extending the result to all mailbox providers without support.
Verify the hosted asset separately
The catalogue requires a public HTTPS fetch with content and certificate evidence in addition to the candidate and validator findings. That fetch should identify the requested endpoint, response status, observed content, bytes or hash, timestamp and TLS validation result. It should establish whether the hosted bytes are the reviewed asset, not merely whether a browser showed something visually similar.
HTTPS transport validation is different from a VMC or CMC associated with the logo. Google's setup guidance requires HTTPS hosting and describes supported mark-evidence files, but a valid hosting certificate does not prove issuer approval of the logo. Preserve both boundaries in the acceptance record. No public endpoint was fetched for an asset here, and no TLS connection evidence is claimed.
A validator findings worksheet
Create a worksheet with candidate hash, rule-set source and version, parser or validator version, each finding, remediation owner and review status. Add separate rows for structural validity, profile requirements, receiver-specific conditions, recommendations, visual review and accessibility. The hosted-asset section should link the fetch evidence and state whether its hash matches the approved candidate.
Use controlled fixtures for a clean candidate and selected failures, but do not fabricate their outcomes. A test should show the expected finding and the actual retained result, including cases the validator cannot assess. If a requirement needs human judgment, label it as such rather than assigning an automated pass. The worksheet proposed here remains unpopulated with original asset evidence.
Fictional diagnosis: a browser-friendly raster wrapper
A fictional designer exports a file that opens correctly in a browser but contains embedded bitmap data. The team assumes the successful preview means the logo is ready for BIMI. The proposed validator review identifies that the relevant profile guidance does not accept that structure and explains the failed requirement rather than blaming an unspecified display problem.
The designer would return to an approved vector source and submit a new candidate for structural and visual review. The team would then verify the hosted bytes and HTTPS evidence separately. This scenario is fictional: no asset was created, converted, uploaded or validated. It illustrates how a useful finding connects a technical restriction to a safe next step without promising receiver display.
Release only with the original asset evidence
The catalogue requires the candidate asset, validator findings and a public HTTPS fetch with content and certificate evidence. All three remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft describes proposed validator behavior and a fictional diagnosis, not a functioning tool or tested EmailAuth feature.