How to fix svg viewbox automatically and standardize online
- Step 1Open the ViewBox Fixer and load your SVG — Drop a single
.svgfile onto the tool above, click to browse, or paste the raw SVG markup into the source box. Only one file at a time in the browser — this tool is not the multi-file uploader (only the sprite builder accepts a batch). Pasted markup is validated as parseable SVG XML before anything runs. - Step 2Decide whether you need padding — Leave the Padding slider at 0 for a box that hugs the content exactly (zero whitespace). Nudge it up if you want a consistent margin around the artwork — every step adds that many user units to all four sides (minX/minY shrink, width/height grow by 2×padding). The browser slider tops out at 20; the API allows up to 50.
- Step 3Process the SVG — Click Process SVG. The tool parses the document, computes the bounding box from the numeric coordinates of every drawn element, and assembles the new
viewBoxstring formatted to at most two decimals with trailing zeros trimmed (so12.00becomes12). - Step 4Read the metrics line — The result reports two values: New viewBox (the exact four-number string written) and Computed bbox —
yesmeans the box came from element geometry,no (fallback)means no coordinates were found and the tool fell back to the declaredviewBox/width/height(defaulting to0 0 24 24if even those are absent). Afallbackresult is a signal to check the file. - Step 5Verify in a browser, not just the editor — Open the downloaded SVG in a browser tab and resize the window, or drop it into a
<div>withwidth:100%. Because the tool removed the pixelwidth/height, it should now fill its container and keep its aspect ratio. If you see clipping or extra whitespace, the bounding box was approximate — see the edge-case notes on curves, arcs and transforms. - Step 6Download and commit — Download the
*-viewbox-fixed.svg. The output is plain SVG markup — diff it against the original in git to confirm only the<svg>attributes changed (viewBox added/replaced, pixel width/height removed and re-added, preserveAspectRatio added). The path data itself is untouched.
What the tool writes to the <svg> tag
Every change the ViewBox Fixer makes to the root element. Inner markup (paths, groups, defs) is never modified — only the <svg> attributes.
| Attribute | Before | After | Rule applied |
|---|---|---|---|
viewBox | Missing, or wrong (e.g. 0 0 100 100 on 24-unit art) | minX minY width height from the computed box | Replaced in place if present; injected onto <svg> if absent |
width (px) | width="512" or width="512px" | width="<box width>" (matches new viewBox) | Original pixel value stripped, then re-added equal to the box size as an overridable default |
height (px) | height="512" or height="512px" | height="<box height>" | Same as width — stripped then re-added |
preserveAspectRatio | Missing | xMidYMid meet | Added only when the SVG has none; an existing value is left untouched |
| Path / shape data | Any d, points, cx, r, … | Unchanged | The tool never rewrites geometry — it only reads coordinates to size the box |
The single option and its limits
The ViewBox Fixer exposes exactly one option. There is no batch upload, no preset list, no crop/align UI in the browser tool — those claims belong to other tools.
| Option | Default | Browser UI range | API / runner range | Effect |
|---|---|---|---|---|
addPadding (Padding slider) | 0 | 0–20 (slider, step 1) | 0–50 (validated; >50 rejected with an error) | Adds N user units on all four sides: minX-=N, minY-=N, width+=2N, height+=2N |
Cookbook
Real before/after fragments. The <pre> blocks show the root <svg> tag only — inner paths are elided with … to keep the focus on what changes.
Missing viewBox on a 24-unit icon
A hand-coded icon with only width/height and no viewBox. The tool reads the path coordinates (which span 0–24 here), computes the box, injects the viewBox, strips the pixel dimensions and adds preserveAspectRatio.
Before: <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24"> <path d="M3 3 H21 V21 H3 Z"/> </svg> After (Padding 0): <svg xmlns="http://www.w3.org/2000/svg" width="18" height="18" preserveAspectRatio="xMidYMid meet" viewBox="3 3 18 18"> <path d="M3 3 H21 V21 H3 Z"/> </svg> Note: the box hugs the drawn rectangle (3→21 = 18), not the nominal 0 0 24 24.
Oversized viewBox leaving whitespace
Artwork sits in the top-left of a 100×100 viewBox but only fills 0–40. Setting width:100% in CSS made it look tiny inside a big empty box. The fixer re-crops to the real bounds.
Before: <svg viewBox="0 0 100 100" width="100" height="100"> <circle cx="20" cy="20" r="20"/> … </svg> After (Padding 0): <svg preserveAspectRatio="xMidYMid meet" viewBox="0 0 40 40" width="40" height="40"> <circle cx="20" cy="20" r="20"/> … </svg> The circle (cx-r=0 to cx+r=40) now fills the box edge to edge.
Adding breathing room with padding
Same circle, but you want an 8-unit margin so the shape doesn't touch the icon edge in a button. Set the Padding slider to 8.
Source content: circle cx=20 cy=20 r=20 (bounds 0,0 → 40,40) Padding 0 → viewBox="0 0 40 40" Padding 8 → viewBox="-8 -8 56 56" minX/minY move by -8; width/height grow by 2×8=16. The shape stays centred; the box gains an even margin.
Fractional bounds get trimmed to two decimals
Exporters often emit long fractional coordinates. The new viewBox is formatted to at most two decimals, with trailing zeros removed, so it stays readable.
Source: path spanning x 1.4999→23.5001, y 2.0→22.0 Computed box: 1.5 2 22 20 (values rounded to 2dp; 22.0001-1.4999 ≈ 22.0002 → "22") Result viewBox="1.5 2 22 20" — no 10-digit float noise.
No geometry found → declared-dimension fallback
An SVG whose only content is a <text> element or an <image> reference exposes no rect/circle/path coordinates, so the box can't be computed. The tool falls back to the declared viewBox or width/height (24×24 if neither exists) and the metrics line flags it.
Before: <svg width="120" height="60"><text x="10" y="30">Hi</text></svg> Metrics: New viewBox = 0 0 120 60 ; Computed bbox = no (fallback) After: <svg preserveAspectRatio="xMidYMid meet" viewBox="0 0 120 60" width="120" height="60"><text x="10" y="30">Hi</text></svg> The box came from width/height, not from measuring the text — verify it looks right.
Edge cases and what actually happens
Path uses curves (C / S / Q / T) — control points inflate the box
ApproximateThe bounding box is built by pairing every number in the d attribute as an (x,y) point. For curve commands the control points are coordinates too, so they're included in the box even though the rendered curve never reaches them. Result: the box can be slightly larger than the visible artwork. It's a safe over-estimate (nothing gets clipped) but not a tight crop. For pixel-tight bounds on curve-heavy art, open the SVG in a vector editor and use its 'fit canvas to drawing' command.
Path uses arc commands (A) — radii and flags mis-read as coordinates
ApproximateAn elliptical-arc command is A rx ry x-axis-rotation large-arc-flag sweep-flag x y. The tool pairs numbers blindly, so rx, ry, the rotation and the two flags get treated as coordinate pairs. The computed box can therefore be wrong — too big, too small, or offset — for paths containing arcs. Check the result visually; if the crop is off, the arc parameters are the cause.
Path uses relative commands (lowercase m, l, c…)
ApproximateRelative commands express each point as a delta from the previous point, but the tool reads the raw numbers as absolute coordinates. A path like m100,100 l10,10 l10,10 actually walks to (120,120) but the numbers seen are 100,100,10,10,10,10 → the box looks like it spans 10→100. Convert to absolute coordinates first (most editors do this on 'simplify' or via the path simplifier for polyline paths) for an accurate box.
Elements carry a transform attribute
IgnoredThe tool reads geometry attributes (x, cx, points, d) directly and does not apply any transform="translate(...)", scale(...), rotate(...) or matrix(...). A shape moved or scaled by a transform is measured in its untransformed coordinate space, so the box won't match where the shape actually renders. Flatten transforms in your editor before fixing the viewBox if your SVG relies on them.
SVG contains only <text> or <image>
FallbackText glyph bounds and raster <image> dimensions aren't read by the coordinate walker, so a document made only of those exposes no measurable geometry. The tool returns Computed bbox = no (fallback) and uses the declared viewBox/width/height instead (24×24 if none). The output is still valid SVG, but the box wasn't measured from the content — verify it.
Malformed / unparseable SVG
RejectedPasted markup is checked with isValidSvg before processing; if it can't be parsed as SVG XML you get 'Invalid SVG — could not parse the pasted content as valid SVG XML.' For files that parse but contain a parser-error node, the bounding-box step returns null and the tool falls back to declared dimensions rather than crashing.
Existing preserveAspectRatio is kept
PreservedIf your SVG already has a preserveAspectRatio (e.g. none for a stretch-to-fit banner, or xMinYMin slice for a crop), the tool leaves it alone — it only adds xMidYMid meet when none is present. Your intentional aspect-ratio behaviour survives the fix.
File over the tier size limit
BlockedThe browser tool enforces the SVG size ceiling before processing: 5 MB on free, 50 MB on Pro, up to 2 GB on Developer. A file above your tier's limit is rejected with an upgrade message. SVGs are text, so 5 MB is enormous for an icon — hitting this usually means embedded base64 rasters, which the viewBox fixer can't measure anyway.
Width/height carried units other than px
PreservedThe strip step only removes numeric/px width and height (e.g. width="512" or width="512px"). Values with other units such as width="100%" or width="3em" are not matched by the strip pattern, so they remain. The viewBox is still set correctly, but you may want to remove a leftover 100% manually if you intended CSS to drive sizing.
Multiple disconnected shapes
SupportedWhen the SVG has several separate elements, the box is the union of all their extents — the smallest rectangle that contains every measured rect, circle, ellipse, line, polygon, polyline and path. This is exactly what you want for a multi-part icon: the viewBox frames the whole composition, not just the first shape.
Frequently asked questions
What exactly does 'fix' mean here — does it redraw my artwork?
No. It only changes attributes on the root <svg> tag. It computes a viewBox from your element coordinates, removes the absolute width/height pixel attributes, re-adds them equal to the new box size, and adds preserveAspectRatio="xMidYMid meet" if you have none. Every path, d, points and shape attribute is left byte-for-byte unchanged.
Why did my fixed viewBox come out smaller than 0 0 24 24?
Because the box hugs the real content, not the nominal canvas. If your icon's strokes only span coordinates 2→22, the box becomes 2 2 20 20. That's correct behaviour — it removes the dead margin. If you want a uniform 24-unit grid (so all your icons share a frame), don't use auto-fit: keep the nominal 0 0 24 24 viewBox and design within it, as the design-system standards guide explains.
How accurate is the bounding box?
Exact for straight-line geometry: rect, circle, ellipse, line, polygon, polyline, and paths made of straight segments with absolute coordinates. Approximate for paths that use curves (the control points inflate the box), arcs (the radii/flags get mis-read as points), or relative commands (deltas read as absolutes). The result is valid SVG either way, but for curve-heavy art treat the box as a safe over-estimate and verify visually.
Does it handle transforms?
No. It reads x, cx, points, d and friends directly and ignores any transform on the element or its parents. A shape moved by transform="translate(50,0)" is measured at its pre-transform position, so the box won't match the rendered location. Flatten transforms in a vector editor first if your file depends on them.
Why does the tool remove width and height?
Hard-coded width="512" height="512" pins the SVG to a fixed pixel size and defeats CSS-driven responsive scaling. After stripping them the tool re-adds width/height equal to the new viewBox dimensions as a sensible default you can override in CSS (svg { width:100%; height:auto; }). With a correct viewBox, that's all you need for crisp scaling at any size.
Can I add a margin around my icon?
Yes — that's the Padding slider. Each unit adds that many user units to all four sides: minX and minY decrease by the padding, width and height grow by twice the padding. The browser slider goes 0–20; if you drive the tool through the API or runner, addPadding accepts 0–50 (values above 50 are rejected with an error).
What does 'Computed bbox = no (fallback)' mean in the metrics?
It means no measurable geometry was found — typically an SVG made only of <text>, <image>, or filters/gradients with no drawn shapes. The tool fell back to the declared viewBox/width/height (24×24 if none exist) instead of measuring the content. The output is valid, but the box wasn't derived from your artwork, so eyeball it.
Can I process a whole folder of icons at once?
Not in the browser tool — it accepts one SVG at a time (only the sprite builder takes a multi-file batch). For folders, drive the tool programmatically via the paired @jadapps/runner; see the batch-standardization guide for a Node script that walks a directory and POSTs each file to the local runner.
Is my SVG uploaded anywhere?
No. The browser tool parses and rewrites the SVG entirely in your tab using the built-in DOMParser — the file never leaves your machine. The cloud API is deliberately upload-free as well: it returns the tool schema and tells clients to run the transform through their own local runner.
My icon still has whitespace after fixing — why?
Two common causes. (1) The artwork uses curves or arcs, so the box over-estimates to be safe. (2) There's an invisible element (a transparent rect background, a stray full-canvas shape) whose coordinates the tool legitimately measured. Remove the invisible element, or run the unused-defs purger / metadata scrubber first, then re-fix.
What's the difference between this and the responsive wrapper?
This tool fixes the SVG file's own viewBox so the markup is internally correct. The responsive wrapper goes one step further and emits an HTML/CSS aspect-ratio container to drop the SVG into a page. Fix the viewBox first, then wrap it — the wrapper reads the corrected viewBox to compute the aspect ratio.
Does it change the coordinate precision of my paths?
No — path data is untouched. Only the four numbers in the new viewBox (and the re-added width/height) are formatted, to a maximum of two decimals with trailing zeros trimmed. If you want to round the actual path coordinates, use the precision tuner before or after fixing the viewBox.
Will this break an SVG that's referenced by <use> or as a sprite symbol?
It can. A <symbol> inside a sprite relies on a deliberate viewBox that the referencing <use> expects. Re-cropping it to content bounds can shift how it renders at the use site. Run the fixer on individual icons before they go into a sprite, then build the sheet with the sprite builder — don't re-fix the assembled sprite.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.