SVG to JPG — Browser-Side Vector Rasteriser at Any Resolution
Rasterise SVG vector graphics (W3C SVG 1.1 Second Edition, Recommendation 16 August 2011 / W3C SVG 2 Candidate Recommendation 4 October 2018, with active development continuing as the Editor's Draft at svgwg.org/svg2-draft) to the universally compatible JPG format using the WHATWG HTML Living Standard Canvas 2D Context drawImage() pipeline (html.spec.whatwg.org/#dom-context-2d-drawimage). The browser loads the SVG into an HTMLImageElement, draws it onto a canvas at your chosen target dimensions, and serialises the bitmap as JFIF-wrapped JPEG (Hamilton, C-Cube Microsystems, 1 September 1992; ITU-T T.81 baseline DCT, 18 September 1992) via HTMLCanvasElement.toBlob('image/jpeg', quality). SVGs loaded via the img element are processed in 'secure static mode' or 'secure animated mode' per the SVG 2 §2.2.4 (secure animated mode) / §2.2.6 (secure static mode) conformance rules — scripts and external resources are blocked, so the rasterisation step cannot execute SVG-embedded JavaScript. Quality 1–100 maps to JPEG quantisation table scaling per ITU-T T.81 Annex K. Since JPEG has no alpha channel, transparent SVG regions are composited against a configurable background colour (default white) before encoding. Rasterisation occurs in the canvas pixel buffer's sRGB encoding (IEC 61966-2-1:1999) regardless of the SVG's declared colour profile. Files never leave the device.
How to convert SVG to JPG
- Drop a .svg file onto the tool or click to browse. The browser parses the SVG via its built-in SVG renderer (loaded as <img> in secure mode — scripts and external resources blocked).
- Pick the output dimensions. Larger pixel sizes produce sharper raster output but heavier JPEG files; choose 2× the display size for Retina screens, or the exact target the destination expects.
- Set the JPG quality level (1–100). 85 is the standard web sweet spot per ITU-T T.81 Annex K; 90+ approaches visually lossless; below 70 produces visible blocking and ringing.
- Choose a background colour for the alpha composite — transparent SVG regions are filled against this colour before JPEG encoding (default white).
- Download the JPG. The original SVG stays on disk untouched — files never leave the device.
Common use cases
- Producing raster JPG versions of vector logos for platforms that reject .svg uploads (most non-design CMSes, social media platforms, print workflows).
- Rendering SVG icons at a specific pixel size for a presentation slide, document figure, or design hand-off where the destination expects raster.
- Creating JPG fallbacks for email templates where SVG support is patchy across mail clients (Outlook desktop notably lacks reliable SVG rendering).
- Exporting SVG artwork as JPG for stock-photo submissions, image banks, or analytics dashboards that require raster input formats.
- Producing fixed-resolution JPG variants from a single SVG master for responsive image srcset entries (1× / 2× / 3× variants).
Frequently asked questions
Why would I rasterise an infinitely-scalable SVG?
Because many destinations only accept raster formats — email clients (Outlook desktop notably), legacy CMSes, social media uploads, print workflows, stock-photo submissions, analytics dashboards. Once rasterised, the JPG has fixed dimensions; choose them carefully (2× display size for Retina, or the exact pixel target the destination expects). The original SVG remains on disk for future re-rasterisation at different sizes.
Are scripts inside the SVG executed during conversion?
No. SVGs loaded via the <img> element are processed in 'secure static mode' or 'secure animated mode' per W3C SVG 2 §2.2.4 (secure animated mode) / §2.2.6 (secure static mode) conformance rules — scripts, external HTTP loads, and DOM scripting are all blocked. This tool uses the <img> path deliberately so a malicious SVG cannot exfiltrate data or run code during rasterisation. SVGs loaded via <object> or inline <svg> would run scripts; this tool does not use those paths.
What size should I render at?
Pick twice the display size for Retina / high-DPI screens, or the exact pixel size the destination expects. Going larger than needed inflates the JPG file size without visible benefit since the destination will downscale it anyway. SVG can render at any resolution losslessly, so re-rasterising at a different target is always cheaper than starting from a too-small JPG.
Does the SVG lose any detail in the JPG?
SVG is vector so there is no lost detail until rasterisation. The JPG will look as sharp as the chosen pixel resolution allows; beyond that size it blurs on zoom because raster pixels cannot be reconstructed losslessly. Re-encoding to JPG also introduces lossy quantisation per ITU-T T.81 Annex K — at quality 85+ the loss is usually invisible; below 70 it becomes visible. For lossless raster output use the svg-to-png tool instead.
What about SVGs containing foreignObject?
SVGs that include <foreignObject> elements taint the canvas (origin-clean = false) per WHATWG html.spec.whatwg.org issue #10641, which causes toBlob() to throw a SecurityError. The conversion will fail. Plain SVGs (paths, shapes, text, gradients, filter primitives) rasterise cleanly. If your SVG has foreignObject content, remove or pre-render it in a desktop editor before bringing it into this tool.
Why rasterise an infinitely-scalable SVG — and the secure-mode + foreignObject caveats
SVG's vector representation scales without precision loss, but many destinations require fixed-pixel raster input — JPG is the universally accepted lowest common denominator. The conversion is a two-step pipeline: (1) the browser parses the SVG and renders it into an HTMLImageElement at the target dimensions, applying CSS, gradients, filter primitives, and font fallbacks; (2) drawImage() copies that rendered bitmap to a canvas, where toBlob('image/jpeg', quality) re-encodes via the browser's built-in JPEG encoder. Quality control (1–100) maps to JPEG quantisation table scaling per ITU-T T.81 Annex K — 85 is the standard web sweet spot, 90+ approaches visually lossless, below 70 produces visible 8×8 blocking and ringing. Two security caveats apply: (a) SVGs loaded via <img> run in secure mode — scripts, external HTTP loads, and DOM scripting are blocked. SVGs loaded via <object> or inline <svg> in HTML execute scripts and CAN load external resources, so this tool deliberately uses the <img> path. (b) SVGs containing <foreignObject> taint the canvas (origin-clean = false) per WHATWG html.spec.whatwg.org issue #10641, which means toBlob() will throw a SecurityError. Plain SVGs (paths, shapes, text, gradients, filters) rasterise cleanly. Output is typically larger than the source SVG for icon-style content (vector paths compress smaller than DCT-coded raster equivalents) but smaller for photographically-detailed SVG content. Rasterisation operates in 8-bit sRGB per IEC 61966-2-1:1999 — wide-gamut colour declarations in the SVG (CSS color-mix(), Display P3 colour values) are tone-mapped to sRGB during the drawImage step.
- Source SVG parsed per W3C SVG 1.1 Second Edition (16 August 2011) + SVG 2 Candidate Recommendation
- Browser-side rasterisation via WHATWG Canvas drawImage with SVGImageElement (secure static / animated mode)
- Custom output width and height — render at the exact pixel size the destination needs
- Aspect-ratio lock toggle — preserve the SVG's native viewBox proportions
- Adjustable JPEG quality 1–100 mapped to ITU-T T.81 Annex K quantisation tables
- Configurable background colour for alpha compositing (transparent SVG → opaque JPEG)
- Output JFIF v1.02 container (Hamilton, C-Cube Microsystems, 1 September 1992)
- Operates in sRGB (IEC 61966-2-1:1999) at 8-bit precision; SVG colour values rasterise to sRGB
Free. No signup. No file uploads. Ads via AdSense (consent required).
Sources (6)
- W3C (SVG Working Group) (2011). Scalable Vector Graphics (SVG) 1.1 (Second Edition). W3C Recommendation 16 August 2011 (w3.org/TR/SVG11/) — source SVG bitstream specification; defines path/shape/text/filter elements, ViewBox + preserveAspectRatio scaling, and the 'secure static mode' / 'secure animated mode' processing rules that apply when an SVG is loaded as an image.
- W3C (SVG Working Group) (2018). Scalable Vector Graphics (SVG) 2. W3C Candidate Recommendation 4 October 2018 (w3.org/TR/SVG2/; active development continues as the Editor's Draft at svgwg.org/svg2-draft, last updated September 2025) — successor spec carrying CSS3 integration, geometry property unification, and the modern hatching/markers used by browser-side SVG renderers.
- WHATWG (live). HTML Living Standard — Canvas 2D Context: drawImage() with SVGImageElement. html.spec.whatwg.org/#dom-context-2d-drawimage + canvas section 4.12.5 — browser rasterisation mechanism: load SVG into HTMLImageElement → drawImage onto canvas at target pixel dimensions → toBlob('image/jpeg', quality). SVGs loaded via <img> are processed in secure mode (scripts and external resources blocked); SVGs containing <foreignObject> taint the canvas (origin-clean = false). Issue github.com/whatwg/html/issues/10641 (filed September 2024) tracks the normative discussion of SVG-as-Image canvas-tainting interop.
- ITU-T (CCITT) Study Group VIII & ISO/IEC JTC 1/SC 29/WG 10 (JPEG) (1992). Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — target JPEG baseline DCT bitstream; quality 1–100 maps to Annex K quantisation tables.
- Hamilton, E. (C-Cube Microsystems) (1992). JPEG File Interchange Format (JFIF) Version 1.02. 1 September 1992 — target de facto JPEG container; APP0 marker, density units, thumbnail handling.
- International Electrotechnical Commission (IEC) (1999). Multimedia systems and equipment — Colour measurement and management — Part 2-1: Default RGB colour space — sRGB. IEC 61966-2-1:1999 — default 8-bit RGB colour space the Canvas 2D path operates in; SVG colour stops in CSS named colours, hex, or RGB are interpreted as sRGB during rasterisation.
These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.