svg.wtf

SVG.wtf is a browser-based SVG editing surface that pairs a visual canvas with live markup, so it suits developers and coders who want to sketch a shape visually and immediately see or edit the underlying SVG code. If your work is mostly dragging shapes around in a design tool and never touching markup, it is probably not the right fit; if you regularly hand-write or inspect SVG and want a faster way to prototype, it is worth a look.

Who gets the most out of it

The tool is aimed at people who are comfortable reading and writing SVG source. The page presents a single workspace where a GUI sits alongside the code, which means the value comes from moving between the two rather than from either one alone.

Typical users:

• Front-end and web developers who need a quick icon, logo, or decorative shape and would rather generate the path than calculate coordinates by hand.
• Developers debugging existing SVG who want to paste markup in, see it rendered, and adjust values while watching the result.
• People learning SVG who benefit from seeing how a change in the code changes the picture, and vice versa.

Typical use cases

Quick prototyping

You need a simple graphic for a page and don't want to open a full vector editor. You draw the shape on the canvas, then copy the generated markup into your project. The canvas handles the geometry; the code panel gives you something you can paste.

Code inspection and small edits

You have an SVG from somewhere else and want to understand or tweak it. Loading it into a view that shows both the render and the source lets you trace which element produces which part of the image.

Learning by doing

Because the visual result and the markup are visible together, changing a coordinate or an attribute and watching the shape move is a direct way to build intuition for how SVG elements behave.

The trade-off to understand

The appeal of SVG.wtf is the balance between GUI convenience and direct code access. You are not choosing between "design tool" and "text editor" — you get both in one view. That is also its limitation: it is a lightweight editing surface, not a full illustration suite. If you need complex path operations, layer management, or export pipelines, a dedicated vector editor will do more.

When it is not the right choice

• You want to produce finished illustrations with heavy manipulation and don't care about the markup.
• You need a full design system or asset pipeline rather than a single-file editing surface.
• You are looking for a hosted service with accounts, sync, or team features — nothing on the page indicates those exist.

How to decide

The practical test is simple: open it, draw one shape, and check whether the code it produces is something you would actually paste into your work. If yes, it fits your workflow.

SVG.wtf is a browser-based SVG editor aimed at developers. Its interface exposes a small, fixed set of drawing tools and utility actions: you pick a shape or text tool, draw or place it on the canvas, and then use the utility actions to clear, download, copy, pin, or snapshot your work. The page evidence also shows focus-lock and move-above/move-below controls for managing elements in the stack.

Drawing tools

The editor lists these tools for creating SVG elements:

These map directly to standard SVG element names, so if you already know SVG markup, the tool names tell you what each one produces in the code.

Utility actions

The interface shows a row of actions:

• clear — removes the current content from the canvas.
• download — exports the SVG file to your machine.
• copy — copies the SVG (typically the markup) to your clipboard.
• pin — pins an element or state, keeping it fixed in place.
• snapshot — captures the current state of the canvas.

The page evidence also includes gui code snapshots automation tools, which suggests the editor pairs a visual GUI with generated code and snapshot/automation features.

Focus lock and element ordering

Two controls manage how elements behave in the stack:

• Click to lock focus — locks focus onto a specific element so edits apply to it rather than to whatever is under the cursor.
• Move above / Move below — reorders the selected element in the layer stack, changing which element renders on top.

Who this is for

The tool set is oriented toward developers working with SVG: the element names match SVG syntax, and the presence of code, snapshots, and automation tools points to a workflow where you draw visually and then take the resulting markup into your own project.

If you want to know whether the visual editor and the code stay in sync as you edit, that is a separate question about the editor's behavior rather than its tool list.

SVG.wtf is a browser-based SVG editing tool that combines a visual canvas with live code and snapshot controls. It is aimed at developers and designers who want to draw or adjust SVG shapes directly, then copy, download, or pin the resulting markup. The page is a working tool rather than a general website or documentation hub, so you go there to create and export SVG code, not to read tutorials.

What the tool actually does

The interface pairs a drawing canvas with a code panel. On the canvas you can add and manipulate standard SVG primitives, and the code side reflects the result so you can move between visual editing and hand-editing.

The shape set visible in the tool covers the core SVG elements:

• rect
• circle
• ellipse
• line
• polyline
• polygon
• path
• image
• text
• textPath

That list matters because it tells you the tool is built around native SVG elements rather than a proprietary format. Anything you draw maps to standard markup you can paste into a web project.

GUI controls and code snapshots

Two features distinguish it from a plain drawing app:

GUI controls. You manipulate shapes through on-canvas handles and a control panel instead of writing coordinates by hand. This is useful when you know roughly what you want but don't want to calculate path data manually.

Snapshots. The tool includes snapshot controls, so you can capture a state of your work and return to it. Combined with the code view, this lets you experiment with a shape, save the version you like, and keep iterating without losing a working result.

The toolbar also exposes actions for the output: clear, download, copy, and pin. In practice that means the workflow ends in either a file on disk or markup on your clipboard, ready for a code editor.

Where it fits in a developer workflow

A typical use looks like this:

1. Open the tool and add the shapes you need from the element list.
2. Adjust them visually with the GUI controls until the composition is right.
3. Check the generated code, editing it directly if you need precise values.
4. Take a snapshot if you want to preserve this state before trying something else.
5. Copy the markup or download the file and paste it into your project.

This suits small, self-contained graphics: icons, simple illustrations, diagram fragments, or a one-off shape you'd rather draw than hand-code. For complex illustrations with many layers, a full vector editor will usually be faster, and for production icon systems you may still want a build step that optimizes the output.

What it is not

It is not a general-purpose website, a tutorial collection, or a documentation portal, despite being labeled a developer resource. There is no indication of pricing, accounts, or paid tiers on the page, so treat it as a tool you open and use rather than a service with a sign-up flow. If you need collaboration features, version history beyond local snapshots, or asset management, this is not that.

When to use it

Choose SVG.wtf when you want to go from "I need a shape" to "I have the SVG code" in one place, with the option to switch between dragging handles and editing markup. Skip it if your graphic is complex enough to need layers, effects, or a full design toolchain.

Yes. SVG.wtf presents a GUI editing surface and a code view side by side, and edits made in the GUI are reflected in the code. The page evidence shows a toolbar with shape tools (rect, circle, ellipse, line, polyline, polygon, path, image, text, textPath) alongside a code area, plus controls for clear, download, copy, pin, and snapshot. That combination is what makes the two views work as one document rather than two separate files.

How the two views relate

The GUI is the input surface; the code is the serialized result. When you draw or adjust a shape with a tool, the tool writes the corresponding SVG element into the code. The code view is therefore a live representation of what the canvas contains, not a separate file you have to keep in sync by hand.

The practical consequence: you can work in whichever view suits the task. Rough positioning and quick shape creation are faster in the GUI; precise coordinates, attribute values, or hand-tuned paths are easier to type directly in the code.

What the toolbar controls do

copy and download are the export path: once the drawing looks right, you take the code out and drop it into your own project. pin and snapshot are the save path: they let you hold onto a particular version of the document instead of losing it the moment you keep editing.

Working order that avoids rework

1. Add the shapes you need with the GUI tools.
2. Switch to the code view and correct exact values — positions, sizes, fill and stroke attributes.
3. Use snapshot at points you might want to return to, and pin the version you intend to keep.
4. Use copy or download to take the final code out.

The main friction point is precision: GUI dragging gets you close, but exact alignment usually means editing numbers in the code. Doing step 2 before you snapshot saves you from pinning a version you'll immediately change.

When this fits your workflow

This setup suits quick icon or diagram work where you want to see the shape while you write it, and it suits learning SVG because the code updates as you draw. It is less suited to large, multi-file SVG projects, where a full editor with a file tree and version control will serve you better.

SVG.wtf is a browser-based SVG editor that pairs a visual canvas with a live code view. You pick a shape tool from the toolbar, draw on the canvas, and the tool writes the corresponding SVG element into the code panel. It suits quick icon sketching, prototyping a shape before hand-tuning the markup, or generating a clean SVG snippet to copy or download. Everything below is based on the tool's visible interface: the shape list (rect, circle, ellipse, line, polyline, polygon, path, image, text), the focus/move/delete controls, and the clear, download, copy, and pin actions.

Available shape tools

The toolbar exposes one entry per SVG element, so what you draw maps directly to standard markup:

Text has a second variant in the interface: a textPath option, which renders text along a path rather than in a straight line. The canvas also shows sample text ("Hi there") for both the plain text and textPath cases, which helps you see the difference before committing.

Drawing a shape

1. Select the shape tool you want from the toolbar.
2. Draw or place it on the canvas. The tool creates the matching element and adds it to the code view.
3. Switch to the code view to confirm the element appeared with its attributes.
4. Adjust the shape on the canvas; the code updates to match.

The key behavior to internalize is that canvas and code are two views of the same document. You don't export from one to the other — an edit in either place is reflected in the other.

GUI controls: focus, move, delete

Each shape on the canvas carries its own small control cluster:

• Click to lock focus — pins your attention to that shape so subsequent actions apply to it rather than to whatever is under the cursor.
• Move below / Move above — reorders the shape in the stacking order. This matters because SVG paints in document order: the later element sits on top. Moving a shape "above" brings it forward; "below" sends it back.
• x Delete — removes the selected shape from the canvas and its element from the code.

Locking focus first is the reliable habit. If you try to move or delete without a locked target, you risk acting on the wrong element, especially when shapes overlap.

How changes appear in the code view

Every canvas action writes to the code panel:

• Drawing a shape inserts a new element.
• Moving or resizing it updates the relevant attributes (position and size values).
• Reordering with Move above/below changes the element's order in the markup.
• Deleting removes the element entirely.

Because the code view is live, you can read it as a running record of what you've done. If a shape looks wrong on the canvas, the code view usually shows why — a missing attribute, an unexpected coordinate, or an element sitting in the wrong order.

Document-level actions

Alongside the per-shape controls, the interface provides four document actions:

• clear — wipes the current drawing, giving you a blank canvas and empty code.
• download — saves the SVG as a file.
• copy — puts the SVG markup on your clipboard for pasting elsewhere.
• pin snapshot — captures the current state as a snapshot you can pin, useful for keeping a known-good version before you experiment further.

A practical workflow: build the shape, pin snapshot once it looks right, then keep editing. If an experiment goes wrong, you still have the pinned version as your reference point. When you're done, copy for inline use or download for a standalone file.

Common snags

• Shape hidden behind another. SVG stacking is order-dependent. Use Move above to bring it forward.
• Actions hitting the wrong element. Lock focus on the target first.
• Text not following a curve. Plain text stays straight; use the textPath variant when you want text along a path.
• Code and canvas out of sync in your head. Re-read the code view after each edit — it's the source of truth for what will be exported.
• Losing work mid-experiment. Pin a snapshot before making large changes.

When this workflow fits

Use SVG.wtf when you want a shape drawn and its markup in hand quickly, and when seeing the code alongside the canvas helps you learn or verify the SVG. For precise, coordinate-driven work or large multi-element illustrations, the canvas-first approach is slower than writing markup directly — in that case, treat the tool as a way to draft a shape and then refine the code by hand.