DEV Community: Usman Bashir

SVG to JPG: What Actually Changes During the Conversion

Usman Bashir — Mon, 17 Aug 2026 14:46:53 +0000

Converting SVG to JPG renders the vector artwork into a fixed grid of pixels, then compresses that grid using JPEG's lossy algorithm. Transparent areas become white, because JPEG has no alpha channel. Everything else about what changes during that process is a choice you can control.

Vector to raster

An SVG is a set of instructions: paths, shapes, fills, strokes. A JPEG is a grid of pixels. The conversion is rasterization: the browser draws the SVG on a canvas at a specific pixel size, then encodes that canvas as a JPEG file.

This is why you cannot simply rename an SVG to .jpg. The two formats describe images in fundamentally different ways. Rasterization is a one-way operation: you can always go from SVG to JPEG, but you cannot recover the original vector data from a JPEG.

Transparency becomes white

JPEG does not support transparency. If your SVG has transparent areas, those areas become solid white in the JPEG output. This happens at the canvas level, before compression: the renderer fills the canvas with a white background, then draws the SVG on top.

If white is not the right background for your use case, use PNG instead. PNG supports transparency and is the right format when the background matters. Use JPEG when you know the image will always sit on a white or light background, or when file size is a higher priority than transparency.

Quality and compression

JPEG compression is lossy. It divides the image into blocks and discards information the eye is least likely to notice. A lower quality setting discards more, producing a smaller file but introducing visible artifacts: blocky patterns around sharp edges and colour banding in flat areas.

Four quality settings you will commonly see (70%, 80%, 90%, 100%):

70%: smallest file; noticeable artifacts on shapes with sharp edges or solid fills. JPEG's compression was designed for photographs, where colour varies gradually. Geometric artwork from an SVG breaks that assumption, so artifacts appear more visibly at lower quality than they would on a photo.
80%: reasonable for most screen use.
90%: good quality with moderate file size reduction.
100%: no quantization reduction applied. The DCT transform still runs, so JPEG at 100% is technically still lossy, but artifacts are not visible under normal viewing conditions.

For SVG-derived content with solid colour fills and crisp geometric edges, the difference between quality settings is more visible than it would be for a photograph. If you see blocky artifacts or colour fringing, go higher.

Scale and resolution

The scale setting controls how many pixels to use when rasterizing. SVG Lab offers 1x, 2x, and 4x:

1x: one output pixel per CSS pixel of the SVG's stated dimensions.
2x: double the width and height, four times the pixel count.
4x: four times the width and height, sixteen times the pixel count.

For screen use, 2x is a reasonable default because it covers high density displays without an unnecessarily large file. 4x makes sense for print, for images that will be displayed much larger than the SVG's native dimensions, or when the reader is expected to zoom in.

When to use JPG vs PNG vs SVG

Keep SVG for icons, logos, and illustrations that need to scale cleanly or will be embedded directly in HTML.
Use PNG when you need a raster file and the image has transparency or hard geometric edges. PNG is lossless; solid colours and crisp shapes compress without artifacts.
Use JPG when you need a raster file, transparency is not required, and file size is a concern. JPG handles photographs and complex images well. For flat geometric artwork, PNG is a better choice because JPEG's compression algorithm was not designed for that kind of content.

Quick answers

Why is my JPG white where the SVG was transparent?
JPEG does not support transparency. Any transparent area is filled with white when the SVG is drawn onto the canvas. Use PNG if you need to preserve transparency.

What quality setting should I use?
80% is a reasonable default for most screen use. Go higher if you see visible artifacts, especially around sharp edges or solid colour fills. Go lower only if file size is a hard constraint.

What scale should I use?
2x is a reasonable default for screen use. Use 4x for print or when the image will be displayed much larger than its native SVG dimensions.

Can I convert back from JPG to SVG?
Not directly. The JPEG contains only pixels, not the original vector paths. Tracing a JPEG produces a new SVG as a reconstruction, not a round-trip conversion.

How to Resize an SVG Without Distorting It

Usman Bashir — Mon, 17 Aug 2026 14:46:41 +0000

Resizing an SVG means changing the width and height attributes on the root <svg> element. If the SVG has a viewBox, you usually leave it unchanged. The shapes and paths inside the file do not change at all.

That is the short version. The reason it gets confusing is that SVG has two separate concepts involved: the size the file says it is, and the coordinate space its artwork was drawn in. They are related but not the same thing, and knowing the difference helps you resize with the result you actually want.

Width and height: the display size

The width and height attributes on the root <svg> element tell a browser how much space to give the image by default. They are a rendering hint, not the fixed dimensions of the artwork:

<svg width="400" height="300" viewBox="0 0 400 300">
  <!-- artwork here -->
</svg>

If you change width to 800 and height to 600, the image renders twice as large on screen. The artwork inside scales to fill that space. Nothing about the coordinates of the shapes inside changed.

ViewBox: the coordinate space

The viewBox attribute defines the internal coordinate system the artwork was drawn in. Its four values are min-x min-y width height:

viewBox="0 0 400 300"

This means the artwork occupies a space 400 units wide and 300 units tall, starting at the top-left corner. When you set the outer width and height, the browser maps those internal units to pixels automatically.

For a straight resize where you want the same artwork at a different display size, you only need to change the outer width and height. The viewBox stays the same, and the browser scales the artwork to match.

Changing viewBox is not the same as resizing

Changing the viewBox values without touching width and height changes what portion of the coordinate space is visible, which crops or zooms the artwork rather than scales it. For a standard resize, leave viewBox alone.

What happens when an SVG has no viewBox

Some SVGs are exported without a viewBox. They have width and height but no coordinate system defined:

<svg width="400" height="300">
  <!-- artwork here -->
</svg>

Without a viewBox, scaling the file can produce unexpected results depending on how the SVG is embedded. The reliable fix is to add a viewBox that matches the current width and height, which establishes the coordinate space explicitly before any resize:

<svg width="400" height="300" viewBox="0 0 400 300">

Aspect ratio

If you change width and height independently without preserving the ratio between them, the artwork distorts. When using a resize tool with an aspect ratio lock, changing width recalculates height automatically to keep proportions intact. Without the lock, you are responsible for keeping the math consistent.

What the resize operation actually touches

A correct SVG resize edits only the root <svg> element's width, height, and viewBox attributes. It does not touch paths, shapes, groups, or styles inside the file. The artwork is identical before and after; only the size metadata changes.

This is also why resizing an SVG does not degrade it. SVG is a vector format. No rasterization happens, no information is discarded, and the file size stays nearly the same. Resizing an SVG is not a way to reduce file weight; it is purely a metadata edit.

Quick answers

Does resizing an SVG reduce quality?
No. SVG is a vector format. Changing the attributes does not rasterize the file or discard any information.

What if my SVG looks squished after resizing?
You probably changed width and height independently without maintaining the aspect ratio. Keep the ratio consistent, or use a tool with an aspect ratio lock.

What about SVG files with no viewBox?
Add a viewBox first, using the file's existing width and height values as the coordinate range. This makes the file behave predictably when you then change the display dimensions.

Do the paths inside the SVG change?
No. The resize only touches the root <svg> element's attributes. Everything inside is unchanged.

Why Your SVG to PDF Export Rasterizes (and How to Stop It)

Usman Bashir — Thu, 13 Aug 2026 04:52:43 +0000

Print the SVG to PDF from a browser, or run it through a vector toolchain. Either way, the output can stay fully vector, because SVG and PDF are both path-based formats. The catch is that most of the common ways people do this rasterize part or all of the document without any error telling you it happened.

The interesting question isn't "how do I convert SVG to PDF." It's "how do I convert it without turning vectors into a bitmap, and what specifically breaks when I do." That's what this post covers.

Same model, different container

SVG and PDF both describe drawings as paths, fills, strokes, and transforms. Converting one to the other is closer to re-encoding the same instructions than redrawing the artwork. Compare that to SVG to PNG, where you're committing to a pixel grid permanently. A correct SVG to PDF conversion keeps every path as a path down to the anchor points, not as sampled pixels.

Whether you actually get that depends on the conversion route and what the SVG contains.

The browser print route, step by step

Open the SVG in a browser tab as real rendered markup, not as a linked image.
Trigger print, either via keyboard shortcut or programmatically:

window.print();

Choose "Save as PDF" as the print destination instead of a physical printer.
Save.

The browser's print pipeline renders SVG the same way it displays it on screen, so paths and (usually) text survive as vector data. What breaks isn't the print step, it's everything upstream of it.

The unit mismatch that crops your drawing

SVG's default unit is the CSS pixel at 96 dpi. PDF and print contexts think in physical units. Without an explicit page size, you inherit the browser's default (commonly A4 or Letter) with its own margins, and your artwork gets shrunk, centered, or cropped inside it.

The conversion is:

mm = px * 25.4 / 96

An 800 by 600 unitless SVG works out to roughly 211.67mm by 158.75mm (800 * 25.4 / 96 = 211.666..., 600 * 25.4 / 96 = 158.75). Set @page to that exact size with zero margin, and the PDF page becomes the artwork instead of a default sheet with the artwork floating inside it:

@page {
  size: 211.67mm 158.75mm;
  margin: 0;
}

Skip this and you get a PDF that renders fine on screen but exports tiny, off-center, or clipped. It's a page size problem, not a rendering bug.

Text-to-paths is a real trade-off, not a free upgrade

If a <text> element references a font that isn't available at print time, the browser substitutes something else, and line wraps, overflow, and spacing all shift with it. Converting text to paths sidesteps that entirely: every glyph becomes a vector shape, so layout is locked in regardless of what fonts exist on whatever machine opens the PDF later.

But converted text is no longer text. It doesn't select, it doesn't search, copy-paste from the PDF returns nothing useful. If the document needs to stay searchable, you have to solve font availability instead, you can't get both guarantees from the same export.

Inline everything or it silently vanishes

Images referenced by URL, external stylesheets loaded via <link> or @import, anything the print context can't resolve synchronously: none of it errors, it just doesn't appear. Convert linked images to base64 data URIs and fold external CSS into an inline <style> block before you print. Missing images in an otherwise-correct export is almost always this.

Filters and masks are the real rasterization trigger

This is the one that catches people who did the page size and fonts and inlining correctly. Filters, masks, clip paths, and blend modes commonly get flattened to a bitmap for just that region, even while the rest of the document stays vector. A Gaussian blur or a complex mask usually can't be expressed as PDF path data, so the renderer rasterizes that piece at whatever resolution the print pipeline picked. "My PDF is vector except this one blurred shape" is the expected outcome of using those effects, not a bug in your export.

Verifying the output is actually vector

Two checks, both fast:

Zoom past 400 percent in a PDF viewer. Vector paths stay crisp at any zoom. Pixel edges or a soft stair-step mean that region was rasterized.
Try selecting text with the viewer's text tool. If it highlights as text, it's still text. If nothing selects, it's paths (or wasn't text to start with).

Where SVG Lab's PDF export sits in all this

SVG Lab (the editor I built, at svglab.app) has PDF in its export menu next to SVG and PNG. The implementation is exactly the print-to-PDF route above: it opens a print-only window with the SVG inlined, computes an @page size from the document's own dimensions using the same px-to-mm math, then calls window.print() so the browser dialog handles the actual "Save as PDF" step. Worth saying plainly: this is a print-to-PDF flow, not a server-side converter, and because it opens a new window, a pop-up blocker can stop it (the app surfaces a status message telling you to allow pop-ups when that happens). Export is gated behind sign-in.

Quick answers

Does the conversion lose quality? Only where something rasterizes. Paths, fills, and strokes translate losslessly. Filters, masks, blend modes, and fixed-pixel rendering are the usual culprits when it doesn't.

Do I need to install anything? No. Any current browser can print an SVG to PDF via the built-in dialog. A CLI vector tool is only worth reaching for if you're batch-converting many files.

Why did I get a blank PDF? Check for a blocked pop-up window first if your tool opens one, then check for external stylesheets or images that didn't resolve in the print context.

Why did my text reflow? Font substitution: the referenced font wasn't available at print time. Fix the font availability, or convert text to paths and accept that it's no longer selectable or searchable.

Building an SVG Editor as a Non-Designer

Usman Bashir — Tue, 11 Aug 2026 14:38:40 +0000

I'm not a designer. I can picture a design clearly enough in my head, but getting an AI assistant like Claude or Codex to actually produce the SVG I was picturing was a grind: vague prompts, wrong outputs, round after round of "no, not like that" iterations that never quite closed the gap between what I imagined and what came back.

Every time that happened, I was facing the same choice: keep spending days trying to prompt a design into existence, or spend an afternoon building a small tool that let me just do it myself, in minutes, exactly as imagined. I kept choosing the tool. That's how SVG Lab happened: a free browser SVG editor, no install, that lets me draw whatever I'm picturing, place it anywhere, and drop it straight into whatever device-screen UI I'm building. That specific task, getting a design out of my head and into a real interface, had been genuinely hard to do through AI assistants alone, for someone without a design background.

Then the SVGs needed to move

Once I had static SVGs I was happy with, the next problem showed up immediately: they needed animation, and there was no tool that let me just try different animations on my own artwork to see what actually fit. I'd load an SVG somewhere and either get a fixed preset that didn't match, or a code-first animation tool that assumed I already knew what I was building toward.

The real block wasn't motion design skill: it was vocabulary. I didn't know what the animations I was imagining were actually called. Was it a "stroke draw-in"? A "path morph"? I genuinely didn't know the term, which meant I couldn't even write a prompt for it. You can't ask an AI for something you can't name.

So I built a small animator instead: load an SVG, click through a set of preset animations, watch each one play on your own artwork, and pick by eye. Discovery instead of vocabulary: you don't need the term if you can just look at it happening on the thing you actually made.

The part that stung the most

The clearest version of this whole pattern showed up when I made the launch video for SVG Lab, a 25-second clip, mostly animated SVGs, built with HyperFrames through Codex. It took days. Same root cause as everything above: I didn't know which animations existed or what to call the motion I had in my head, so I couldn't direct the AI toward it.

Eventually I gave up on getting my own vision out. I found someone else's launch video on X, showed it to Codex, and said "make something like this." What came back was fine. It worked. But it wasn't the video in my head, it was someone else's video, wearing my product's name.

That one stuck with me more than the others, because it wasn't a drawing or an animation preset: it was the actual launch, the thing meant to represent the whole project, and I ended up shipping a compromise on it. The lesson I keep coming back to: people shouldn't have to give up on their own vision for something as important as how they introduce what they built. The marketing video is one of the last steps after the actual product is done, and it's exactly the kind of step where "just describe it to the AI" quietly stops working if you don't have the vocabulary, and most builders don't.

Where this is going

SVG Lab and the animator aren't meant to stay small utilities to me. The direction I want to take this is a platform that handles the whole design process, end to end, for people who can build software but can't design it: the same "thousands of new developers and vibe coders like me" I'd guess make up a lot of anyone reading this. App builders should be able to grab the animated SVG or its code directly for their project, with no separate video step in the way. Founders and marketers should be able to compose animated SVGs into scenes and render an actual launch video from inside the same tool, instead of hitting the wall I hit.

That's still a direction, not a finished thing. Some of this is genuinely built today, some of it is still ahead. But the throughline hasn't changed since the first version: I can't always name what I want, and I shouldn't have to, to get it made.

If any of this sounds familiar (you can build the thing but the design step keeps costing you days you don't have), SVG Lab is free to try. Prefer to start with one task instead of the whole editor? The SVG to PNG converter and the other single-purpose tools sit outside the app too, for exactly that.

More at svglab.app.

The SVG Color Cascade Nobody Explains (fill, stroke, currentColor, and why img src breaks it)

Usman Bashir — Fri, 07 Aug 2026 17:53:57 +0000

Change an SVG's color by editing fill and stroke, either as attributes or through CSS. Simple in theory. In practice there are three places a color can be declared in the same file, they follow the normal CSS cascade, and if you don't know that, "I changed the fill and nothing happened" turns into a twenty-minute debugging session.

Here's the part of SVG color handling that usually doesn't get spelled out.

fill and stroke are separate properties

Every shape has an inside (fill) and an outline (stroke), set independently:

<circle cx="50" cy="50" r="40" fill="#3366ff" stroke="#000" stroke-width="2" />

Unset fill defaults to black. Unset stroke defaults to none. If an icon is pure fill with no stroke at all (most converted icon-font SVGs are), editing stroke-width is never going to do anything visible, and that's usually the first dead end people hit.

The cascade is the actual bug source

A color can come from three places, and they don't have equal priority:

A presentation attribute: <path fill="red" />
An inline style attribute: <path style="fill: red;" />
A <style> block or external stylesheet: path { fill: red; }

Normal CSS specificity applies: style attribute beats stylesheet, stylesheet beats presentation attribute. Edit the fill="red" attribute directly, and if a <style> block elsewhere in the same file also targets that path, your edit is overridden and nothing changes on screen. No error, no warning, it just loses.

If a color edit isn't sticking, grep the file for <style before assuming your tool, or your edit, is broken. This one thing accounts for most "the SVG editor is buggy" reports that are actually the cascade working exactly as designed.

currentColor: SVG's inheritance trick

Set fill="currentColor" and the shape stops carrying its own color and instead inherits whatever color is set to on an ancestor element, the same mechanism that makes text inherit color:

<path fill="currentColor" d="..." />

.icon { color: #ff0000; }

<span class="icon"><svg fill="currentColor">...</svg></span>

Change .icon's color and the SVG updates with zero edits to the SVG itself. It's why most icon libraries ship currentColor by default: one file, infinite colors, controlled entirely by CSS at the call site. If you're publishing your own icon set, this is the property to reach for instead of hardcoding hex values into every export.

The one that actually surprises people: `<img src>`

<img src="icon.svg" />

The moment an SVG is referenced this way, the browser treats it as an opaque raster-like image. There's no DOM access, no CSS targeting fill, and currentColor resolves to nothing because there's no inheritance path across the document boundary. filter: invert() gets you a rough approximation at best, not a real color swap.

Three actual fixes, in order of how much they cost you:

Inline the SVG in the HTML. Once the markup is literally on the page, it's a normal element and every CSS trick above works.

Use it as a mask instead of a source:

.icon {
  background-color: currentColor;
  mask: url(icon.svg) center / contain no-repeat;
  -webkit-mask: url(icon.svg) center / contain no-repeat;
}

The shape becomes a stencil, the visible color comes from background-color, and you never touch the SVG file.

Use a sprite with <use>, setting fill on the <use> element, assuming the source paths don't already have a hardcoded fill fighting you (see the cascade section above, same rule applies here too).

Multi-path SVGs need more than one edit

A two-tone logo is rarely one shape. It's usually four or five <path> elements, each carrying its own fill. Changing one and expecting the whole icon to shift is the second-most common gotcha after the cascade issue. Either:

put fill="currentColor" on every path that should track the parent's text color, or
set fill on a wrapping <g>, keeping in mind any child path with its own explicit fill still wins over the group value

Past two or three paths this gets tedious fast when you're doing it by hand in a text editor, hunting fill= occurrences one at a time with no visual feedback on which shape you're actually touching.

CSS custom properties work fine inside SVG

<svg>
  <style>
    :root { --icon-color: #3366ff; }
    .body-fill { fill: var(--icon-color); }
  </style>
  <path class="body-fill" d="..." />
</svg>

One variable, referenced by every shape that shares it. If the SVG is inlined (not loaded via img), the page's own CSS can override that variable directly, giving a multi-part graphic a single external color hook instead of duplicated hex values scattered across paths.

Doing this visually

SVG Lab is a free browser SVG editor I built: visual fill and stroke editing plus path and node editing (bezier control points, anchor manipulation), no install. It doesn't replace knowing how the cascade works, it just means you click the shape you want to change instead of hunting through markup for it.

The SVG Path Data Format, Explained (M, L, C, Q, A, Z)

Usman Bashir — Fri, 07 Aug 2026 17:53:56 +0000

If you've opened a <path d="..."> string and had no idea what you were looking at, here's the short version: it's a tiny drawing language. A pen moves around a coordinate space, and each letter in the string is an instruction telling it what to do next.

TL;DR

M/m moves the pen, L/l draws a straight line, C/c and Q/q draw bezier curves, A/a draws an arc, Z/z closes the shape.
Uppercase is absolute coordinates, lowercase is relative to the pen's current position.
A visual path editor drags the exact same numbers you'd type by hand, it just shows you the curve instead of making you compute it.

Reading a path string

<path d="M10 10 L90 10 L90 90 Z" />

Broken down: move to (10, 10), draw a line to (90, 10), draw a line to (90, 90), close the path back to the start. That's a right triangle. Every path, no matter how complex, is this same pattern: a command letter followed by however many numbers that command needs, repeated.

The command set

Command	Name	What it takes
`M` / `m`	Move to	x, y
`L` / `l`	Line to	x, y
`C` / `c`	Cubic bezier	control1 x/y, control2 x/y, end x/y
`Q` / `q`	Quadratic bezier	control x/y, end x/y
`A` / `a`	Arc	rx, ry, rotation, large-arc-flag, sweep-flag, end x/y
`Z` / `z`	Close path	none

C and Q are both bezier curves, the difference is one control point (Q) vs two (C). Two control points give you more independent influence over each end of the curve; one control point gives you a simpler, more symmetric curve. There are also shorthand continuations (S/s, T/t) for chaining smooth curves without repeating a control point, but the six above are what you'll hit constantly.

A is the one people avoid writing by hand. Six parameters, two of which are flags (0 or 1) that determine which of four possible arcs you get for the same radii and endpoints. Flip one and you're not slightly off, you're on the opposite side of the ellipse.

Absolute vs relative is the part that bites

Every command above has an uppercase and lowercase form, and it's not cosmetic:

<!-- absolute: go to (90, 10) -->
<path d="M0 0 L90 10" />

<!-- relative: go 90 right, 10 down, from wherever the pen is -->
<path d="M0 0 l90 10" />

In this example both produce the same triangle, because the pen starts at the origin. They stop agreeing the moment you edit one segment in the middle of a longer relative path: every command after your edit is relative to a starting point that just moved, so the rest of the shape shifts with it. This is the single most common cause of "I changed one line and now the whole icon is wrong" when hand-editing SVG.

Why this gets painful fast

None of the commands above are individually hard. What breaks down is scale. A real icon or illustration is often one unbroken string with dozens of commands, no line breaks, no comments, and bezier control points that don't even sit on the visible curve, they pull it from outside. Reading four numbers and predicting the resulting curve shape in your head is not something most people can do reliably, so editing path data by hand usually turns into: change a number, re-render, squint, change it again.

What a visual editor is actually doing

Worth being precise here, since it's easy to assume there's something clever happening under the hood. There isn't. A path editor renders two things you can drag:

Anchor points: the actual M/L/curve-endpoint coordinates in the string.
Control handles: the control points belonging to C and Q commands, shown as draggable lines coming off an anchor.

Drag an anchor, you change where a segment starts or ends. Drag a handle, you change the curvature of the segment it belongs to, without touching the anchor. Every drag is a rewrite of the same numbers you'd otherwise be typing into the d string yourself. The editor's only job is closing the loop between "I changed a number" and "here's what that number now looks like," instantly, instead of making you simulate it.

Gotchas worth knowing before you debug one of these

Z draws a line back to the start. An unexpected extra segment in a shape is often just Z doing exactly that.
Arc flags (large-arc-flag, sweep-flag) are booleans, not tuning knobs. Wrong flag, wrong side of the ellipse, not a small deviation.
Editing inside a relative-coordinate path shifts everything downstream of the edit. If you're scripting path transformations, absolute coordinates are usually safer to reason about.
Aggressively rounding coordinates to shrink file size can leave visible seams where two paths are supposed to meet exactly.

If you'd rather drag than compute

For small, deliberate edits, working in the raw d string is fine once you know the command set. For anything with more curves than you can hold in your head, dragging nodes and watching the render update is faster than mentally running the bezier math.

SVG Lab is a free, no-install browser editor with real node and bezier handle editing on top of the raw path data, plus fill and stroke color editing. Not the only way to do this, just one option if you want to see the curve instead of computing it.

How SVG-to-PNG Conversion Actually Works in the Browser

Usman Bashir — Thu, 06 Aug 2026 07:55:03 +0000

If you've ever tried to convert an SVG to a PNG entirely in the browser (no server round-trip, no ImageMagick, just JavaScript), you've probably hit a point where the output looked almost right and you couldn't figure out why it wasn't quite right. The mechanics are simple in outline and full of small traps in practice. This is a walkthrough of how the conversion actually works, and where it usually breaks.

The basic pipeline

There's no native "SVG to PNG" API. The browser gives you two lower-level primitives and expects you to combine them:

Load the SVG as an Image object (or draw it via a data URL / object URL).
Draw that image onto a <canvas> element.
Read the canvas back out as a PNG via canvas.toBlob() or canvas.toDataURL().

const img = new Image();
const svgBlob = new Blob([svgString], { type: "image/svg+xml;charset=utf-8" });
const url = URL.createObjectURL(svgBlob);

img.onload = () => {
  const canvas = document.createElement("canvas");
  canvas.width = targetWidth;
  canvas.height = targetHeight;
  const ctx = canvas.getContext("2d");
  ctx.drawImage(img, 0, 0, targetWidth, targetHeight);
  canvas.toBlob((blob) => {
    // blob is your PNG
    URL.revokeObjectURL(url);
  }, "image/png");
};
img.src = url;

That's the whole mechanism. Everything else in this post is about the ways this innocent-looking code produces a wrong-looking image.

Rasterization: canvas doesn't know about "vector"

The moment drawImage runs, the SVG stops being a vector graphic. Canvas is a bitmap surface: it rasterizes the image at whatever pixel dimensions the canvas has, right then, and every pixel is committed. There's no going back to redraw it sharper later without re-running the whole pipeline from the source SVG at a new size. This is why "export at 2x" isn't a checkbox on the PNG after the fact; it has to happen before rasterization, by drawing into a larger canvas from the start.

Scale factors and devicePixelRatio

This is the single most common cause of blurry exports. A CSS pixel is not a physical pixel. On a standard display, devicePixelRatio is 1 and they match. On most modern laptop and phone screens, it's 2 or 3, meaning the OS is rendering 2-3 physical pixels for every logical CSS pixel to get a sharp image.

If you size your canvas using the SVG's logical width and height directly, then display or save that canvas at "actual size," you'll get an export that looks soft on any high-density display, because you only rasterized at 1x worth of detail.

The fix is to multiply the canvas dimensions by your target scale factor before drawing, then scale the drawing context to match:

const scale = window.devicePixelRatio || 2; // or a fixed export scale like 2 or 3
canvas.width = targetWidth * scale;
canvas.height = targetHeight * scale;
ctx.scale(scale, scale);
ctx.drawImage(img, 0, 0, targetWidth, targetHeight);

Note that devicePixelRatio reflects the viewing device, not necessarily the scale you want for an exported file. For export tooling, it's usually better to expose scale as an explicit user choice (1x / 2x / 3x, or a target pixel width) rather than silently inheriting whatever screen the export happened to run on.

viewBox vs width/height: which dimensions actually apply

SVG has two, occasionally conflicting, ideas of "size":

The viewBox attribute defines the internal coordinate system: the drawing's own units.
The width/height attributes (or equivalent CSS) define how large the SVG renders in the document.

When both are present, viewBox sets the aspect ratio and coordinate space, and width/height set the actual rendered size: the SVG scales its contents to fit. When an SVG has a viewBox but no explicit width/height, browsers typically fall back to a default intrinsic size (often 300×150), which is rarely what you want for an export. This is a common source of "why did my PNG come out as 300x150" bug reports: the source SVG had a viewBox but nothing telling the rasterizer what pixel size to target, so something upstream picked the default.

For predictable exports, it's worth explicitly setting the target width and height on the canvas yourself, calculated from the viewBox aspect ratio, rather than trusting the SVG's own width/height attributes to be present or correct.

External image references don't resolve

An SVG can reference external raster images via <image href="...">. This works fine when the SVG renders directly in an <img> tag or inline in the DOM, because the browser fetches the reference normally. It breaks in the canvas pipeline for a specific reason: once you draw an image containing external references onto a canvas, the canvas becomes "tainted" if any of those references were loaded cross-origin without proper CORS headers, and toDataURL()/toBlob() will throw a security error rather than silently failing.

Even when CORS isn't the issue, external references add a dependency on network availability and load timing that a self-contained SVG doesn't have: if the referenced image hasn't finished loading when the SVG is rasterized, you get a blank spot where it should be. The most reliable fix for browser-side conversion is to inline external raster references as base64 data URIs before rasterizing, so the SVG carries everything it needs with no additional fetch.

Fonts: embedded vs linked

Text in an SVG is the other common failure point. If an SVG uses <text> with a font that isn't embedded in the SVG itself (just referenced by font-family name, or linked via an external stylesheet/@font-face), the rasterizer falls back to whatever font is available on the system running the conversion, which may not match what the SVG's author intended, and will definitely not match if the conversion runs somewhere the font isn't installed at all (a different machine, a headless environment, etc.).

The robust options are converting text to outlined paths before export (so there's no font dependency left at all), or embedding the font data directly in the SVG as a base64 @font-face inside a <style> block. Linked fonts are the fragile option: they depend on the environment doing the rasterizing having network access and the same font available, which is exactly the kind of thing that works on your machine and breaks the moment the conversion runs somewhere else.

Putting it together

None of these problems are exotic. They're all consequences of the same basic fact: canvas rasterization is a one-shot, environment-dependent process, and an SVG can carry dependencies (external images, linked fonts, ambiguous dimensions) that don't survive that process cleanly. Handling them means: pick an explicit scale factor rather than trusting device defaults, resolve the viewBox/width/height ambiguity explicitly rather than trusting fallbacks, inline external image references, and either outline or embed fonts before rasterizing.

If you'd rather not wire this pipeline up by hand, SVG Lab's SVG-to-PNG tool handles the scale factor, dimension, and font-embedding cases above automatically, worth a look as a working example of the same pipeline described here, running entirely in the browser.

DEV Community: Usman Bashir

SVG to JPG: What Actually Changes During the Conversion

Vector to raster

Transparency becomes white

Quality and compression

Scale and resolution

When to use JPG vs PNG vs SVG

Quick answers

How to Resize an SVG Without Distorting It

Width and height: the display size

ViewBox: the coordinate space

Changing viewBox is not the same as resizing

What happens when an SVG has no viewBox

Aspect ratio

What the resize operation actually touches

Quick answers

Why Your SVG to PDF Export Rasterizes (and How to Stop It)

Same model, different container

The browser print route, step by step

The unit mismatch that crops your drawing

Text-to-paths is a real trade-off, not a free upgrade

Inline everything or it silently vanishes

Filters and masks are the real rasterization trigger

Verifying the output is actually vector

Where SVG Lab's PDF export sits in all this

Quick answers

Building an SVG Editor as a Non-Designer

Then the SVGs needed to move

The part that stung the most

Where this is going

The SVG Color Cascade Nobody Explains (fill, stroke, currentColor, and why img src breaks it)

fill and stroke are separate properties

The cascade is the actual bug source

currentColor: SVG's inheritance trick

The one that actually surprises people: <img src>

Multi-path SVGs need more than one edit

CSS custom properties work fine inside SVG

Doing this visually

The SVG Path Data Format, Explained (M, L, C, Q, A, Z)

Reading a path string

The command set

Absolute vs relative is the part that bites

Why this gets painful fast

What a visual editor is actually doing

Gotchas worth knowing before you debug one of these

If you'd rather drag than compute

How SVG-to-PNG Conversion Actually Works in the Browser

The basic pipeline

Rasterization: canvas doesn't know about "vector"

Scale factors and devicePixelRatio

viewBox vs width/height: which dimensions actually apply

External image references don't resolve

Fonts: embedded vs linked

Putting it together

The one that actually surprises people: `<img src>`