gizmobench

SVG Viewer

Paste SVG markup into the left box, or open a file from your machine, and the drawing renders on the right in a frame that cannot run any of it. An SVG is markup rather than pixels, so it can carry a script, an on* event handler and references to files elsewhere, and opening one in a live document is how a picture gets to do something you never asked for. Two independent things stop that here. The markup is read first, and every script element, foreignObject, event handler attribute, @import rule and reference pointing outside the file is taken out and listed under the stage, while a #fragment into the same file and a picture written in as a data: URL are kept because neither asks anything of anyone. Then the result is rendered in an iframe with an empty sandbox attribute, under a content policy that starts from default-src 'none', so nothing runs and nothing is requested even if the first pass missed something. The reading is the other half: the viewBox, the declared width and height, the byte size and the element structure are printed exactly as your file writes them, each with the rule that produced it, and the zoom runs from 25% to 400% over a checkerboard so transparency is visible.

renderno render

The rendered drawing appears here.

Nothing to look at yet. or

Scripts never runNothing is fetched for the previewYour file stays in this tabNo account, no sign-up
viewBox
not read
Nodes
not read
Size
0 bytes
Zoom

Paste markup that starts with <svg, or open an .svg file from this machine. Nothing leaves your browser.

The preview is empty. Paste SVG markup into the box, or open a file, to see it rendered.

  • Valid SVG24 by 24
    renders, reports viewBox
  • Missing viewBoxno viewBox
    states it, uses width and height
  • Malformed markupunclosed tag
    parse error, nothing rendered
Why nothing in this file can run. Two things stop it, and either one alone would do. The markup is read before it is shown, and every <script> element, every <foreignObject>, every on* event handler attribute, every @import and every reference that points outside this file is taken out and listed above; a #fragment that points back into the same file and a picture written in as a data: URL are kept, because neither asks anything of anyone. Then the result is rendered in an iframe with an empty sandbox attribute, which is a document in an origin of its own with no permission to run code, submit a form, open a window or navigate anything, and that document carries default-src 'none'; img-src data:; font-src data:; style-src 'unsafe-inline', so every request it could still make is refused. Your file is never uploaded: up to 200,000 characters of it is kept in this browser alone so it is still here when you come back, and the Start over button above forgets it.

Up to 2 MB of markup at a time, which is 2,097,152 bytes. That is a memory bound rather than an upload limit. The preview rebuilds when you stop typing, so a long paste is rendered once rather than on every keystroke.

Accuracy. Your file renders in a sandboxed frame that is given no permission to run code and no way to reach the network, so scripts, event handlers and external references are stripped before the preview and never execute or load. The viewBox, the declared width and height and the element counts are read from your markup and reported exactly as the file declares them, in the units it uses. It cannot show you a font your machine does not have or an image the file loads from somewhere else, and it says which references it withheld.

Common questions

Is it safe to open an SVG someone sent me?
That is the question this viewer was built around, and two separate things answer it. First, the markup is read before anything is shown, and every script element and foreignObject is removed with its contents, every on* event handler attribute is removed, every @import inside a style element is removed, and every href, xlink:href or url() that points outside the file is removed. Second, what survives that is rendered in an iframe whose sandbox attribute is empty, which puts it in an origin of its own with no permission to run code, submit a form, open a window or navigate anything, and the document in that frame carries default-src 'none'; img-src data:; font-src data:; style-src 'unsafe-inline', so every request it could still make is refused. Either half alone would stop a hostile file. What the tool will not do is tell you the drawing itself is harmless: it reports what it took out and lets you read the source.
Why does my SVG look different here than in a design program?
Because anything that had to be loaded from somewhere else is not loaded. A file that draws with a web font falls back to a font your machine already has, an image element pointing at a photo on a server renders empty, and a stylesheet pulled in with @import is not applied. The list under the stage names each of those, counted from your own file rather than printed as a standing warning, so a missing logo is explainable rather than mysterious. Styling written inside the document, in a style element or a style attribute, is applied normally, and a picture embedded as a data: URL renders, because it carries its own bytes and asks for nothing.
My file has no viewBox. What size does the viewer show it at?
It follows the same order a browser does, and says which rule applied. Width and height attributes in an absolute unit, which means a plain number of pixels, or px, pt, pc, in, cm, mm or Q, are the file's own size and win. A file that declares only one of them takes the other from the viewBox ratio, or from the browser's own default when there is no viewBox to take a ratio from. A file that declares neither is drawn at its viewBox in user units, one unit to one pixel at 100% zoom. A file that declares nothing usable, including a width given as a percentage or in em, falls to 300 by 150 pixels, which is what a browser gives a picture with no intrinsic size, and the line under the readout says so rather than presenting that number as the file's size.
What happens when the markup does not parse?
Nothing is rendered, and the message names the line and what to do. A tag that opens and never reaches its closing angle bracket, an element closed by the wrong closing tag, a closing tag that was never opened, a comment that never reaches its end, and an element left open at the end of the file each get their own message with a line number. That is often the reason you opened a viewer in the first place: a half-copied paste or a truncated download looks fine until something tries to read it.
How large a file can I open?
Up to 2 MB of markup at a time, which is 2,097,152 bytes. That is a memory bound rather than an upload limit, because nothing is uploaded: past roughly that size the re-read on every keystroke is slow enough that the tool feels broken. The size cell counts bytes rather than characters, so ordinary ASCII markup costs one byte per character while accented or CJK text costs two or three. Past the limit the tool says how large the file is and how large it may be, and renders nothing, rather than quietly cutting the file short and showing you a drawing that is missing its ending.
Is my file uploaded anywhere?
No. The reading and the rendering both happen in your own browser, so there is no server in this, no account to make and nothing sent or logged. The tool makes no network request of its own, and the policy in the preview refuses every request your file asks for. Your draft is remembered in this browser alone so it is still there when you come back: up to 200,000 characters of it is written to local storage, a longer file is still read and rendered in full but is not stored, and the Start over button above the tool forgets whatever was kept.
Can I copy the markup or save it out?
Yes to both. Copy puts whatever is in the source box on your clipboard, exactly as you pasted or typed it, and the box is a plain text area, so you can also select and edit it by hand. Download writes out the checked markup, which is your file with the scripts, handlers and external references already removed, as drawing.svg. The two are deliberately different: one is what you gave the viewer, the other is what the preview actually rendered.
What do the structure list and the node count tell me?
The node count in the readout names the elements inside the root when they are all of one kind, so a simple icon reads as 1 path instead of 2 elements, and counts the whole document when it is more mixed. The structure list under the tool is every element in document order, indented by depth, with its id where it has one, which is the fastest way to see the shape of a drawing somebody sent you and the quickest way to find the group you want to edit. A file with more than 400 elements has the list shortened and says so; the counts above it always cover the whole file.

Your file renders in a sandboxed frame that is given no permission to run code and no way to reach the network, so scripts, event handlers and external references are stripped before the preview and never execute or load. The viewBox, the declared width and height and the element counts are read from your markup and reported exactly as the file declares them, in the units it uses. It cannot show you a font your machine does not have or an image the file loads from somewhere else, and it says which references it withheld.