SVG Viewer
Render an uploaded or pasted SVG live, then pan and zoom to inspect it. Everything runs locally in your browser.
Loading tools...
How the SVG Viewer works
Drop an .svg file or paste raw SVG markup into the text box, and it renders instantly in the preview pane below. Scroll (or use the zoom buttons) to magnify fine details, and click-drag to pan around — handy for inspecting icons, illustrations, and complex vector graphics whose detail is easy to miss at 100%. The toolbar reports the declared width, height, and viewBoxattributes from the SVG's root element alongside the file size, so you can quickly sanity-check an exported asset before shipping it.
The preview renders your markup as a sandboxed image, so embedded scripts never execute against the page. Everything — parsing, rendering, pan, and zoom — happens locally; the file is never uploaded anywhere. Need to edit the markup itself? Try the XML Formatter to pretty-print it first.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Rendering a pasted SVG to see what it actually contains.
- Checking an SVG's dimensions and file size before using it.
- Panning and zooming to inspect detail in a complex drawing.
- Confirming an SVG renders at all before committing it.
- Inspecting an SVG you were sent without opening an editor.
Frequently Asked Questions
- What is the viewBox actually doing?
- Defining the coordinate system the shapes are drawn in, and how it maps onto whatever size the element is given. `viewBox="0 0 100 100"` means the drawing is 100 units square; the CSS width then scales that, which is what makes SVG resolution-independent.
- Why does my SVG not scale?
- Usually a missing viewBox, or fixed `width`/`height` attributes overriding the CSS. Without a viewBox there is no coordinate system to map from, so the browser treats the intrinsic size as fixed and the image refuses to grow with its container.
- Is it safe to open an untrusted SVG?
- Not blindly — SVG is XML that can contain `<script>`, event handlers and external references, which is why it is a known vector for stored XSS when served from your own origin. Viewing one inline means executing it; sanitising or rendering it as an `<img>` does not.
- Why is my exported SVG so large?
- Design tools emit a great deal of redundancy: full-precision path coordinates, empty groups, editor metadata and unused definitions. Rounding coordinates to two decimals and stripping metadata routinely halves the file with no visible difference.
- Inline SVG or an img tag?
- Inline when CSS or JavaScript must reach the shapes — hover colours, animation, theming with `currentColor`. `<img>` when it is a static picture, because the browser caches it separately and it cannot execute anything. The security difference alone often decides it.
Common errors and gotchas
- Rendering an SVG from an untrusted source, which can carry script and external references.
- Assuming a missing viewBox is a rendering problem rather than the file's own omission.
- Expecting external fonts and images to resolve, which they often will not.
- Judging file size before minification, which for SVG is usually substantial.
- Reading a blank render as a broken file, when it may simply have no fill declared.