Repository navigation
New Vite SVG logo renders incorrectly in WebKit #23588
Description
Describe the bug
The official Vite light and dark SVG logos can render inconsistently in WebKit when displayed at small icon sizes.
Affected official assets:
These assets were introduced by #21339.
In WebKit 27 on macOS 27, rendering either SVG at approximately 24px height can produce:
- A soft or blurry appearance
- Color bleeding around the lightning mark
- Incorrect dark edges or outlines
- Incorrect interpolation around transparent regions
Chrome 153 renders the same files correctly.
The screenshot below shows the worst-case WebKit rendering: the logo is completely incorrect. In ordinary cases, WebKit is usually not this severe, but it still appears noticeably blurrier than Chrome.
WebKit issue screenshot from the downstream VitePress report:
The official SVG files contain:
- 15 elements
- 15 effects
- 1 element
- viewBox: 0 0 87 15
These filter and mask effects appear to be rasterized differently by WebKit and Chromium.
This also affects downstream consumers. VitePress documented the same issue and applied a raster fallback in vuejs/vitepress#5466.
Reproduction
Note: htmlpreview.github.io may occasionally fail to render the HTML. The issue can also be tested directly with the official vite-light.svg and vite-dark.svg files at approximately 24px height.
Steps to reproduce
- Open the reproduction URL in WebKit 27 on macOS 27.
- Display the official Vite light/dark SVG logos at approximately 24px height.
- Compare the rendering with Chrome 153 at the same size.
- Observe the blur, color bleeding, and incorrect edges in WebKit.
System Info
System:
OS: macOS 27.0 (26A428)
CPU: Apple M4
Memory: 16 GB
Shell: zsh 5.9
Browsers:
WebKit: 27.0
Chrome: 153.0.8010.53Used Package Manager
npm
Logs
Official Vite logo SVG structure:
- filters: 15
- feGaussianBlur: 15
- masks: 1
- viewBox: 0 0 87 15
Downstream workaround and screenshots:
vuejs/vitepress#5466
Confirmed solution:
- Replace the SVG with pre-rendered image assets, such as PNG or WebP, for small icon usage. This avoids runtime SVG filter and mask processing and produces consistent WebKit/Chromium rendering.
- This is the solution currently used in VitePress PR fix(hmr): client pinging behind a proxy on websocket disconnect (fix #4501) #5466.
Alternative SVG fix:
- Flatten or remove the Gaussian Blur filters and mask from the official SVG so it can render consistently without a raster fallback.
Validations
- Follow our Code of Conduct
- Read the Contributing Guidelines.
- Read the docs.
- Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
- Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
- Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
- The provided reproduction is a minimal reproducible example of the bug.
Activity
[-]Official Vite light/dark SVG logos render incorrectly in Safari at small sizes[/-][+]New Vite SVG logo renders incorrectly in Safari[/+][-]New Vite SVG logo renders incorrectly in Safari[/-][+]New Vite SVG logo renders incorrectly in WebKit[/+]neevmodh commentedon Sep 26, 2026
A fix is up in #23591.
Fix: Replaces the filter/mask-heavy source (15
<feGaussianBlur>filters plus an alpha mask) with a single pre-rasterized PNG at 10x the viewBox resolution, embedded via<image>. This is the fallback recommended in this issue and already adopted for the same assets in vuejs/vitepress#5466. File paths, extensions, andviewBoxare unchanged, so no downstream consumer needs to update anything.Testing: Rendered and visually compared both files before/after — the wordmark and gradient glow are preserved faithfully at the target icon size.
sapphi-red commentedon Sep 29, 2026
It looks fine to me. Safari looks slightly blurry, but only slightly. It doesn't look similar to the "WebKit issue screenshot from the downstream VitePress report" image you shared.
ChisakaKanako commentedon Sep 29, 2026
Sometimes, that’s the worst rendering result, which usually happens after the window is resized. Generally, WebKit looks like this:
It’s not just a little unclear—the entire file is rendered incorrectly. I mean, both situations can trigger this issue, but for this one file, WebKit always displays rendering errors; it doesn’t handle so many SVG effects very well.
sapphi-red commentedon Sep 29, 2026
ok, I reproduced by opening https://vitepress.dev multiple times.
It seems
mask="url(#SVGgudELdDz)"part is ignored. This is definitely a bug in Safari / WebKit rather than a difference of rasterization.bluwy commentedon Oct 1, 2026
I'd prefer waiting for WebKit to fix this.
ChisakaKanako commentedon Oct 1, 2026
Sometimes we have to accept that WebKit's support is always a step behind.
TheAlexLichter commentedon Oct 1, 2026
This is https://bugs.webkit.org/show_bug.cgi?id=325131 or maybe https://bugs.webkit.org/show_bug.cgi?id=282530 I think?