Initializing... drag & drop files here
Supports: X3F
<image> element — no sign-up, no watermark, no email gating. Download individually or as a ZIP.X3F is a raster RAW format — every pixel is sensor data captured by Sigma's three-layer Foveon X3 sensor, with no shape, path, or vector geometry anywhere in the file. SVG is a vector format meant to describe shapes mathematically. There is no algorithm that turns a 14-megapixel photo of a landscape into clean geometric paths and preserves the photo: tracing a photographic image either produces a few hundred lumpy color blobs (lossy and unrecognisable) or hundreds of thousands of micro-paths (huge file, slow to render, no better than the original raster). Both the W3C SVG spec and the FreeConvert / Convertio implementations sidestep this by wrapping the raster — first demosaicing the X3F into a standard RGB raster (PNG or JPEG), then embedding that base64 payload inside an SVG <image> element. The result is technically a valid .svg file, opens in browsers and design tools, and can be placed on an infinitely scalable canvas — but the pixels inside scale exactly like any raster would. This is a feature/bug worth understanding before you commit. If you want a true vector trace (logos, line art, single-color silhouettes), see the alternatives below. Common reasons people still want X3F → SVG:
.svg as a first-class asset. Wrapping the Foveon photo in SVG lets a designer place it on an artboard alongside actual vector UI elements without juggling file formats..svg that any modern browser opens directly; recipients don't need Sigma Photo Pro or a RAW plugin.Need true vector output? Trace tools like Vectorizer.AI or Inkscape's built-in tracer work far better on developed images than on RAW. Convert the X3F to PNG or JPG first, then run a vector trace. For non-photographic line art or logos already in raster form, JPG to SVG or PNG to SVG is a more natural path.
| Property | X3F | SVG |
|---|---|---|
| Type | Raster RAW (sensor-level) | Vector (XML markup) |
| Owner / spec | Sigma Corporation (proprietary) | W3C open standard (SVG 1.1 SE, 2011; SVG 2 Candidate Recommendation in active work) |
| First released | 2002 (Sigma SD9) | SVG 1.0 in 2001; SVG 1.1 in 2003 |
| Stored data | Per-pixel red + green + blue from Foveon's three vertically stacked photodiodes, no demosaic interpolation needed | Shapes, paths, text, gradients, optional embedded raster via <image> |
| Scaling behaviour | Fixed pixel grid; enlarging loses fidelity | True vector parts scale without loss; embedded raster scales like any raster |
| Color model | Wide-gamut sensor data (typically 12-bit per channel, three layers) | sRGB by default; supports ICC profiles, but rare in wrapped output |
| Native viewers | Sigma Photo Pro, Photo Mechanic, RawTherapee, recent Adobe Camera Raw with X3F plugin | Every modern browser, Figma, Sketch, Inkscape, Illustrator, GIMP |
| Editability | Non-destructive RAW edits in Sigma Photo Pro or RawTherapee | Hand-edit XML in any text editor; visual edit in vector apps |
| Typical file size | 20-50 MB per shot (Quattro / Merrill bodies) | A wrapper SVG with embedded base64 raster: roughly the source raster size + ~30% base64 overhead + a few hundred bytes of XML |
| Best for | Maximum colour fidelity straight out of Sigma Foveon cameras | UI assets, logos, web/print graphics, and (with <image>) wrapping a raster in a vector canvas |
| Precision value | What it changes | Pick when |
|---|---|---|
| 1-3 | Coordinates and dimensions written with 1-3 decimal places | Smallest SVG, minor coordinate rounding on very large canvases — fine for a wrapper SVG since the work is in the embedded raster, not the XML geometry |
| 4-6 (default 6) | Coordinates with up to 6 decimal places | Recommended range. Imperceptible at any reasonable display size; matches Inkscape's default precision |
| 7-10 | Coordinates with 7-10 decimal places | Only meaningful if you're projecting the SVG onto an enormous physical canvas (billboards, projection mapping) and want sub-pixel positioning |
Because XConvert's X3F → SVG path embeds the demosaiced raster rather than tracing paths, precision mostly affects metadata and <image> placement coordinates, not perceived image quality. The visible quality of the output is determined by the underlying raster, not the SVG number precision.
Because the SVG generated from a photographic source contains the full pixel data, base64-encoded inside an <image> element. Base64 adds roughly 33% overhead on top of the raw image bytes, plus a few hundred bytes of XML wrapper. So a 6 MB JPEG renders out as a ~8 MB SVG. There is no compression magic — .svg is plain text XML. If file size matters more than the .svg extension, convert your X3F to PNG or JPG instead.
No — and this is the most common misunderstanding. Only the SVG canvas is vector. The embedded photograph is a raster locked at its original pixel dimensions. Enlarge the SVG 10x on screen and the pixels blow up exactly the way they would in a PNG. The "scalable" part of SVG only delivers on pure vector content (paths, shapes, text). To genuinely vectorise a photo you need an image-tracing tool, and even then photographs trace poorly — the technique works for logos, icons, and line art, not landscapes or portraits.
No. The Foveon X3 sensor records red, green, and blue at every pixel via three stacked photodiodes, but that wide-gamut, three-layer raw data is collapsed to a standard 8-bit sRGB raster as part of demosaicing before it's wrapped into the SVG. If you need to preserve the full Foveon colour science, keep the X3F and edit it in Sigma Photo Pro, or export to a 16-bit format like TIFF or DNG instead.
The SVG opens directly in every modern browser, Inkscape, Illustrator, Figma, Sketch, and most operating-system image previews. Photoshop opens SVGs through Place / Open and rasterises them into a layer. Lightroom does not import SVG — it's a vector tool's domain. The camera itself can't display SVG either; it only previews its own X3F and JPEG output.
You can crop, mask, rotate, and apply CSS / SVG filters (blur, hue-rotate, drop-shadow) to the embedded raster. You cannot do tonal RAW edits like exposure recovery or white-balance correction — those need the original X3F in a RAW developer. The practical pattern is: develop the X3F in Sigma Photo Pro or RawTherapee, export a clean JPEG/PNG, then wrap to SVG only if your downstream tool needs the .svg extension.
Sigma Photo Pro doesn't export SVG at all — it exports JPEG, TIFF, and X3I (its multi-shot format). The only way to land at SVG is either (a) re-wrap a developed raster the way XConvert does, or (b) trace a developed raster with a vector tool. XConvert handles (a) directly from the X3F so you don't run Sigma Photo Pro first.
No. Sigma X3F files store XMP and proprietary metadata (camera model, ISO, lens info, shooting date), but none of that becomes editable SVG <text> elements in the output. The metadata is dropped or stuffed into the SVG <title> / <desc> elements depending on the converter. If you need a caption or watermark as real vector text, add it after conversion in Inkscape or Figma.
Files process in your browser session and are removed after the session ends. No account is required and there are no watermarks, file-count limits, or hidden Pro tiers. Because the conversion runs in-browser, X3F files (which can be 20-50 MB each from a Merrill or Quattro body) never leave your machine in a persistent form.
Three realistic paths: (1) develop the X3F to PNG or JPG, then run it through a dedicated tracer like Vectorizer.AI or Inkscape's Path > Trace Bitmap; expect best results on high-contrast subjects (silhouettes, logos against a clear background). (2) Hand-trace key shapes in Illustrator or Figma over the embedded raster as a guide layer. (3) Skip vectorisation entirely and treat the SVG <image> wrapper as a vector-canvas placeholder for the photo — which is what this converter produces.