Image to SVG Converter

Global tools

An SVG file can hold a picture, and that is what this page makes: a real SVG document, one file, with your image inside it and a size you declare - in pixels for the web, or in millimeters for a printer. It is a legitimate job, and often the only way to get a single picture into a layout that insists on a vector file.

Drag & drop files here, or .

Everything is processed in your browser - nothing is uploaded.

    Up to 20 pictures, 25 MB each. Each one becomes its own SVG file, written inside this browser tab - nothing is uploaded.

    Keeping the original bytes is lossless and gives the smallest file; re-encoding as PNG or JPEG makes it open in every SVG reader.

    The picture inside is always the same pixels; this decides how large the file declares itself to be, which is what a page, a slide or a printer reads.

    Only used for the plan below, before any picture is chosen. The real job uses the files themselves.

    Results update as you type. Nothing leaves your device.

    Plan for 3 pictures

    SVG holding the original bytes

    Each picture becomes its own SVG file with the image inside it, declared at its own pixel size. Nothing is uploaded, and nothing is thrown away unless you ask for it.

    Pictures per job
    up to 20
    Inside the SVG
    the file's own bytes
    Opens at
    its pixel size
    Vector art
    no - see below

    What happens when you add pictures

    1. Each picture is read from your device and decoded, so the SVG can declare a pixel size it can stand behind.
    2. The file is copied into the SVG exactly as it arrived - no re-encoding, so nothing at all is lost. The catch is compatibility: whatever opens the SVG has to understand the original format, and JPEG and PNG are the two every SVG consumer does.
    3. The picture is base64-encoded into the SVG, which is why a file of this kind is about a third larger than the picture inside it: three characters of text carry every two bytes of image.
    4. Every SVG downloads on its own, named after the file it came from: photo.jpg becomes photo.svg.
    This is not vector art, and it is worth being blunt about it: an SVG that contains a picture is a container, and the picture inside is still a fixed grid of pixels. Zooming in shows those pixels exactly as the JPEG did. Turning pixels into shapes is called tracing, it only works well on flat art, and a traced photograph is thousands of paths in a much larger file - so this page does not pretend to trace.

    What the SVG can carry

    Inside the SVGGood atWhat it costs
    the picture's own byteskeeping everything exactly as it was, and the smallest SVGThe file is copied into the SVG exactly as it arrived - no re-encoding, so nothing at all is lost. The catch is compatibility: whatever opens the SVG has to understand the original format, and JPEG and PNG are the two every SVG consumer does.
    PNGopening in every SVG reader, with transparency kept exactlyThe pixels are written as PNG, which every SVG reader understands and which keeps transparency exactly. A photograph stored as PNG inside an SVG is several times the size of the JPEG version.
    JPEGthe smallest SVG when the picture is a photographThe pixels are written as JPEG at the quality you choose: the smallest SVG of the three, and the one that cannot carry transparency.

    Whatever the SVG carries has to be understood by whatever opens it: a BMP or an AVIF inside an SVG is not something every editor reads, while JPEG and PNG are.

    A file of this kind is a good way to put one picture into a layout that wants a vector file - a label, a slide, a cutting machine’s uploader, a document that has to stay a single file. If what you need is a picture that stays sharp at any size *because it was redrawn*, that is a different job: send flat art to a tracer, or ask for the original artwork instead.

    The other half of an honest answer is what this file is not. It is not vector art: the picture inside stays a grid of pixels, and zooming in shows them exactly as the JPEG did. Turning pixels into shapes is called tracing, it is a different job that only works well on flat art, and this page says so before you download anything rather than after.

    About this image to svg converter

    Vector art is what most people hope an image-to-SVG converter produces, and it is the one thing this page refuses to fake. It writes a real, self-contained SVG document with your picture inside it and a size you declare, in pixels for the web or millimeters for a printer, which is often the only way a picture enters a layout that insists on a vector file.

    No file is uploaded to make that file: the picture is base64-encoded into a data URL and written as text inside the SVG, and the wrapping runs client-side in your browser, so an unreleased logo or a scanned signature stays on your device. The container scales without artifacts, but the pixels inside it do not gain detail.

    Tracing and wrapping are different jobs: turning pixels into shapes works well on flat art and turns a photograph into thousands of tiny paths and a much larger file, so this page wraps and says so plainly instead of pretending to have vectorized anything. Pick the carrier that suits the reader, original bytes, PNG or JPEG. For true vectors, reach for a dedicated tracer.

    How this image to svg converter works

    What an SVG with a picture inside it actually is

    An SVG document is a text file, and the element that holds a picture is `<image>`. Instead of pointing at a file somewhere it points at a `data:` URL - your picture, base64-encoded, written out as text inside the document. That is why the file is self-contained: send it to somebody and the picture travels with it, with no folder, no missing link and no broken thumbnail.

    Two attributes decide the geometry, and they do different jobs. The `viewBox` is the picture’s own pixel grid - "this drawing is 4000 by 3000 units" - and `width`/`height` are how large the file declares itself to be. Declaring it at 210 mm while the viewBox says 4000 pixels is not a contradiction: it is the entire point of a vector container, and the ratio between the two is the picture’s own, so nothing is ever stretched.

    The file opens in every browser, in Illustrator, Inkscape and Affinity, in Word and PowerPoint, and in the uploaders that want an SVG - because it is a valid SVG document, not an imitation. What it asks of the program opening it is that it understands the format *inside*: JPEG and PNG are universal, while a BMP or an AVIF inside an SVG is not something every editor reads. That is the whole reason this page can re-encode the picture as PNG or JPEG on the way in.

    Pixels in a vector container: what stays sharp and what does not

    The container scales to any size without losing anything, and that is worth having on its own. A 600 pixel PNG placed in a slide at 5 cm normally gets resampled by the layout program, which softens it a little; the same PNG inside an SVG arrives at exactly 600 pixels mapped onto 5 cm, untouched. Transparency survives, the color values are the ones that were in the file, and nothing was re-encoded unless you asked for it.

    What does not happen is more detail. Zoom into the SVG far enough and you see the pixels of the picture inside it, because that is what is there - a fixed grid, written down in text. An SVG of this kind is sharp *at any size the file declares*, and it is the same picture at every one of them. Calling that "vector art" would be a lie, and it is the lie that makes people think an image-to-SVG converter can rescue a small logo.

    So the honest use cases are the ones where a single self-contained file at a controlled size is what matters: a label in a print template, one picture in a slide deck that has to stay one file, a logo on a specification sheet, an uploader that accepts SVG, a document that must not depend on a folder of images. For a photograph that will be viewed at full screen, a plain JPEG is smaller and just as good.

    Tracing, and why this page does not do it

    Turning pixels into shapes has a name: tracing (or vectorising). The usual recipe is to reduce the picture to a handful of colors, find the outline of each color region, simplify those outlines, and write them out as `<path>` elements. Done well on flat art - a logo, an icon, a chart, a scanned signature, a map with four colors - the result is genuinely better than the raster it came from, because it really is shapes.

    Done on a photograph it produces thousands of tiny paths, a file many times larger than the JPEG, and a picture that looks like a poster that has been through a photocopier. That is not a bug in the tracer; it is what happens when you ask a photograph to describe itself with outlines.

    This tool therefore wraps rather than traces, and says which one you need. If you have flat art and want real vectors, a dedicated tracer is the right tool - Inkscape’s "Trace Bitmap" is free and good at exactly this - and nothing here will pretend to have done it.

    Original bytes, PNG or JPEG: the three carriers

    Keeping the picture as it arrived is the smallest, most honest option: the bytes go in exactly, nothing is re-encoded, and the only cost is that the program opening the SVG must understand the format the picture came in. PNG is the safe universal carrier that keeps transparency and costs a larger file; JPEG is the small carrier that cannot keep transparency and loses a little at the quality you choose.

    The choice is on the form and the planned size is printed before you run anything. None of it changes the picture: the viewBox keeps the original pixel grid in every case, so the declared size and the data inside never disagree.

    Worked examples

    Each example below was run through the calculator on this page when the site was built, so the numbers match what you see when you enter the same inputs.

    A photograph, kept exactly as it was

    What the SVG carries: The picture's own bytes, untouched (lossless, smallest)

    Plan for 3 pictures

    SVG holding the original bytes

    Each picture becomes its own SVG file with the image inside it, declared at its own pixel size. Nothing is uploaded, and nothing is thrown away unless you ask for it.

    Pictures per job: up to 20 · Inside the SVG: the file's own bytes · Opens at: its pixel size · Vector art: no - see below

    With the original bytes kept, the picture inside the SVG is the file you uploaded, byte for byte - no re-encoding, no second generation of loss, and the smallest SVG of the three routes. It is also the one where the program that opens the SVG has to understand the format the picture arrived in.

    A logo with a transparent background, for a slide

    What the SVG carries: Re-encoded as PNG inside (lossless pixels, opens everywhere) · How big the SVG opens: Web friendly: pixels, no unit (what a browser assumes)

    Plan for 3 pictures

    SVG holding PNG

    Each picture becomes its own SVG file with the image inside it, declared at its own pixel size. Nothing is uploaded, and nothing is thrown away unless you ask for it.

    Pictures per job: up to 20 · Inside the SVG: PNG · Opens at: its pixel size · Vector art: no - see below

    PNG is understood by every SVG reader and keeps transparency exactly, which is why it is the safe carrier for a logo. The file will be larger than the JPEG version of the same logo, and it will still be the logo’s own pixels: transparency is kept, sharpness beyond those pixels is not created.

    A picture for a printed label, 100 mm wide

    What the SVG carries: Re-encoded as JPEG inside (smallest, no transparency) · JPEG quality (inside the SVG): High (85%) - good for printing · How big the SVG opens: Print: millimeters · Width: 100

    Plan for 3 pictures

    SVG holding JPEG

    Each picture becomes its own SVG file with the image inside it, declared at 100 mm. Nothing is uploaded, and nothing is thrown away unless you ask for it.

    Pictures per job: up to 20 · Inside the SVG: JPEG · Opens at: 100 mm · Vector art: no - see below

    Declaring the size in millimeters tells the print program how large to place it, and the height is worked out from the picture’s own shape - 100 mm wide gives whatever height keeps the aspect ratio. JPEG keeps the file small and cannot keep transparency.

    The same picture at a size nobody has to guess

    How big the SVG opens: Print: inches · Width: 4

    Plan for 3 pictures

    SVG holding the original bytes

    Each picture becomes its own SVG file with the image inside it, declared at 4 in. Nothing is uploaded, and nothing is thrown away unless you ask for it.

    Pictures per job: up to 20 · Inside the SVG: the file's own bytes · Opens at: 4 in · Vector art: no - see below

    Four inches wide, with the height following the picture. The viewBox inside stays the pixel grid, so the file is unambiguous about both what it holds and how big it is - which is exactly what a layout program needs.

    Frequently asked questions

    Is the SVG a real SVG, or a picture with a different extension?

    It is a real SVG document: valid XML, an `<svg>` root with a viewBox, a `<title>`, a description and an `<image>` element - the structure any SVG reader understands. What it is not is artwork made of paths. If a service says it needs "real vector" artwork, it usually means shapes it can recolor and scale without limit; a picture inside an `<image>` element is not that, and this page will not claim otherwise.

    Will the picture stay sharp when I make the SVG bigger?

    The file scales perfectly, because the container is geometry; the picture inside it does not gain detail, because there is no more detail to gain. A 600 pixel logo declared at 20 cm is 600 pixels spread over 20 cm - blurrier than the same logo at 5 cm. If you need sharpness that survives any size, the source has to be shapes rather than pixels: ask for the original artwork, or trace flat art into paths.

    Why is the SVG bigger than the picture I put into it?

    Base64: the picture is written as text, and text carries six bits of picture in every eight characters - so the payload grows by about a third (four characters for every three bytes, exactly). The wrapper adds a few hundred bytes. Keeping the original bytes is therefore the smallest option: 1 MB of JPEG becomes roughly 1.37 MB of SVG and nothing is re-encoded along the way.

    Does this lose any quality?

    With "the picture’s own bytes" it cannot lose anything: the file is copied in exactly as it arrived. With the PNG carrier nothing is lost either, because PNG is a lossless format - the pixels are identical and the file is usually larger. Only the JPEG carrier is lossy, and only as lossy as the quality setting you choose.

    Can I still edit the picture once it is inside the SVG?

    You can move, scale, rotate and replace it - it is one `<image>` element, and every editor treats it as a placed picture. You cannot edit its pixels in an SVG editor, nor recolor parts of it, because it is a picture rather than shapes. Inkscape’s "Trace Bitmap" can turn it into paths afterwards if the artwork is flat enough for that to work; on a photograph it will not be.

    What size should I declare?

    If the file is going on the web, leave it at its own pixel size: the pixel grid and the declared size match, and CSS can scale it as it likes. If it is going into print or a document, declare the width in millimeters, centimeters or inches - 210 mm is the width of A4, 100 mm is a common label width - and the height is calculated from the picture’s own shape. Nothing is stretched either way, because the viewBox inside keeps the original ratio.

    Which format should the SVG carry?

    JPEG for photographs: it is understood everywhere and it is small. PNG for logos, screenshots and anything with transparency. The picture’s own bytes when the file is already JPEG or PNG and you want a guarantee that nothing was re-encoded - it is lossless and the smallest, and the only cost is that the program opening the SVG has to understand the original format.

    What about an animated GIF, a PDF or a TIFF?

    An animated GIF can be carried inside an SVG and browsers usually keep it animating, but print and layout programs show only the first frame - so it works and it is worth knowing where it does not. PDF and TIFF are refused: they are documents rather than web pictures, and there is no sensible meaning for them inside an `<image>` element. An SVG input is refused too, because that is the format this tool writes.

    Assumptions and sources

    • The SVG holds your picture in a single image element, with both the SVG 1.1 and SVG 2 link attributes so the file opens in more places.
    • There is no tracing: the picture is embedded rather than turned into vector paths, so a photograph becomes a larger file and its edges are not converted to curves.
    • Nothing is uploaded: the picture is read and the SVG is written in your browser tab.

    Last reviewed 2026-09-16. Runs locally on your device; keep backups; no financial advice applies. Read the full disclaimer.

    Where a figure on this page comes from an official agency — HUD, IRS, FICO or a state body — the site keeps a dated snapshot of the source page in its sources library, and a scheduled job re-checks that snapshot, so the number can be traced back to the document it came from.