A vector file describes shapes in its own coordinates. Nothing in it has to say what one of those coordinates is worth. When it doesn’t, something has to guess — and the guess is always wrong in the same direction, by the same amount.
Our instant quote has to measure the drawing before it can price it, so it resolves the units in a fixed order. That order is worth knowing, because it explains every “why does this file come out at 264 mm?” we get.
What one unit actually means
An SVG with no unit on its width is interpreted in pixels, and a pixel is 25.4 ÷ 96 = 0.2645833 mm. That is the CSS reference pixel — 96 to the inch — and it is the single most common reason a file measures wrong.
| A drawing whose coordinates span 1000 × 600, sized as… | measures |
|---|---|
width="100mm" | 100.00 × 60.00 mm |
width="10cm" | 100.00 × 60.00 mm |
width="4in" | 101.60 × 60.96 mm |
width="1000" — no unit at all | 264.58 × 158.75 mm |
width="1000px" | 264.58 × 158.75 mm |
viewBox only, no width or height | 264.58 × 158.75 mm |
1000 units became 264.58 mm because 1000 × 0.2645833 = 264.58. Nothing is broken in that file. It genuinely does not specify a unit, so the 96-DPI default applies.
The good news is that when the width does carry a real unit we use it, including scaling the drawing to fit. A viewBox of 100 units exported at width="4in" measures 101.60 mm across, because four inches is 101.6 mm and everything else follows from that.
The order we resolve it in
- If you have told the builder which unit to use, that unit wins, whatever the file says.
- Otherwise, if the width carries a real unit — mm, cm, m, in, ft, pt or pc — and there is a viewBox, the width wins and the drawing scales to it.
- If the width is in pixels and there is a viewBox, we convert at 96 DPI.
- If there is only a viewBox, one unit is one pixel: 0.2645833 mm.
- If none of that resolves, the drawing is measured in pixels.
Forcing the unit is the escape hatch. The same 1000 × 600 drawing, with the unit overridden in the builder:
| Unit forced to | measures |
|---|---|
| mm | 1000.00 × 600.00 mm |
| cm | 10 000.00 × 6 000.00 mm |
| inch | 25 400.00 × 15 240.00 mm |
| px — or left on auto | 264.58 × 158.75 mm |
Notice the last row. Auto and px agree, because when nothing else in the file says otherwise, auto is pixels.
DXF is not exempt
A DXF carries its units in the header, in a variable called $INSUNITS. We read it and convert accordingly:
0or4— millimetres1— inches2— feet5— centimetres6— metres
A drawing with $INSUNITS set to 1 is read as inches throughout — a 25.4-unit circle becomes a 645.16 mm radius, because 25.4 inches is 645.16 mm. If the header is missing we assume millimetres, which is right for most of the files we see and wrong for a few of them. Setting $INSUNITS costs nothing and removes the guess. It is also the first thing in our file prep guide.
Why we measure it again on our side
The browser works out an estimate as you go, so you get a number immediately. The price you are charged is recalculated on the server, from the file itself, before anything is cut. If the two disagree, the server wins. That is deliberate: a file with wrong units produces a wrong estimate, and we would rather catch that than invoice it.
If a drawing does not resolve the way you expect, we tell you which rule fired and what the drawing measured. We do not quietly round it and hope.
The two-line fix
<svg width="120mm" height="80mm" viewBox="0 0 120 80">Now one unit is one millimetre, and the numbers you see are the numbers of the finished part. When you export from Illustrator, Inkscape or Affinity, set the document units to millimetres first and let the exporter write them into the width and height. If you are stuck with pixels, either set $INSUNITS in a DXF or force the unit in the builder for an SVG.
Two attributes. That is the difference between a 100 mm part and a 264.58 mm part.