Image & SVG conversion

Because most SVG optimizers are tuned for byte count, not for the user — and accessibility metadata is, from the compressor's point of view, overhead in the way. SVGO ships with a preset that is technically correct and practically destructive: removeTitle and removeDesc are on by default, and removeUnknownsAndDefaults cheerfully deletes aria-* attributes as "unknown to the SVG spec." So <title>, <desc>, role="img", and the aria-labelledby wiring — exactly the pieces that let a screen reader announce an icon — get stripped on the way to production.

The justification is reasonable for the median file: most SVGs on the open web carry no meaningful accessibility metadata, so leaving the plugins on is the path of least surprise. But design-system icons, app icons, and any graphic meant to convey meaning are precisely the files where those attributes matter most, and precisely the files a team is most likely to push through a build-time optimizer. The regression is invisible in the rendered page — the icon looks correct — and only shows up in the assistive-tech experience, the one place a sighted reviewer never checks.

The common fix, a post-optimization script that adds the attributes back, works but drifts: when the icon set changes, the optimizer is upgraded, or the design system migrates icon families, that second pass is the only thing standing between you and a silent re-regression. The reliable fix is to never let the optimizer touch the attributes in the first place — treat <title> and <desc> as first-class fields in the source, and turn off removeTitle, removeDesc, and removeUnknownsAndDefaults in the config so optimization and accessibility become the same pass.

This request keeps surfacing in software and design threads, and it's worth being precise about what people actually mean, because "image to SVG" covers two very different jobs. The first is format handling: you already have vector or icon files and need them moved between SVG, PNG, WebP and friends reliably, in bulk, without an upload queue. The second is true vectorization — tracing a raster logo into editable SVG paths — which is a genuinely harder problem that even paid tools get only approximately right, and which the builders in these threads describe doing by hand because the manual path is fiddly.

What ties the demand together is context, not sophistication. An SVG conversion is often part of a portfolio deadline, not a design-system migration. The existing options feel fragmented and upload-heavy: one web-app owner watched a Firebase bill spike after an influencer sent thousands of users through a converter that uploaded large JPGs and PNGs to a server. So the ask is a local, private path from an image to the format the next step needs — fast enough for a one-off chore, sturdy enough to repeat.

A practical rule of thumb: reach for a local batch converter when the job is really about format, size, and consistency, and keep expectations honest about automatic raster-to-vector tracing — for logos and icons destined to be edited, starting from a clean vector source almost always beats auto-tracing a photo. Either way, the file never needs to leave your machine to get converted.

This is one of those problems that's easy to dismiss as niche right up until it lands inside an important folder. One bookkeeper's version was bulk image dimension and DPI correction across hundreds of folders — not a creative task, just a correctness task that has to be applied uniformly to a large, messy tree of files. Odd dimensions, wrong DPI, mixed formats, and scattered exports aren't edge cases to the person holding the files; they are the whole job.

Single-purpose web tools feel brittle here because they assume you arrived with one clean input and one clean output in mind. Real batch work is the opposite: the first input may be wrong, incomplete, or mixed with unrelated files, and the tool needs to accept that. What you actually want from a batch resize is control and predictability — apply the same dimension or DPI rule across every folder, get a consistent output location, and keep the originals untouched so a bad run costs you nothing. Metadata removal and duplicate checks often ride along in the same pass, because a folder that needs resizing usually needs a couple of other things cleaned up too.

The important feature in a job this size is not raw speed. It's reviewability: being able to see which files were accepted, which were skipped, and where the outputs will land before you commit an action to a folder full of irreplaceable material.

The honest answer is that it's a trust decision you shouldn't have to make for a task this small, and the default of "upload to whichever converter ranked first" is a weak one. File tools sit close to sensitive material: PDFs can contain contracts, IDs, medical forms, invoices, or internal reports; photo folders can carry location metadata; archives can hold source files or client assets. Handing any of that to a random server just to compress or convert it adds failure modes that have nothing to do with the actual job.

There's a cost story too, not only a privacy one. One web-app owner watched their Firebase bill spike after an influencer drove thousands of users to upload large JPGs and PNGs — a reminder that "upload it to the cloud" is rarely free of consequences, on either side of the connection. The files already live on your machine; moving them to a remote service to compress, OCR, rename, convert, or strip metadata is extra risk for no benefit.

The better default is local processing: you should be able to disconnect from the network and still merge, resize, convert, or clean an image. That doesn't make the task glamorous — it makes a boring task trustworthy. It also makes iteration cheaper, because you can try a setting, compare the output, undo it, and run the next file without wondering whether the server kept a copy or the session expired. For images specifically, the metadata question is concrete: stripping EXIF (including embedded GPS location) before a photo leaves your hands is a one-step job that a local tool can do without ever transmitting the file.

Because the real cost of file work is the switching cost, and single-purpose tools push all of it onto you. A typical job spreads across one site for PDFs, another for images, a desktop app for video, a command-line snippet for archives, and a forum thread for the recovery step — and every switch is another chance to upload the wrong file, lose the output, or forget which copy is current. When each tool has its own trust model, its own upload box, and its own idea of what "convert" means, the workflow tax quietly becomes larger than the file work itself.

This happens because users don't experience file work as tidy product categories. They experience it as a folder that contains everything a real task needs: a PDF to shrink, a batch of images to convert, a clip to export, an SVG to clean up. The adjacent chores keep showing up together — documents, images, browser media, SVGs — which is a clue that the categories are an artifact of how tools are sold, not how work is done.

A local workbench doesn't need to pretend every job is sophisticated. Its value is that the file stays in one predictable place while you move from a PDF action to an image action to a media action without changing trust models each time. Breadth here doesn't mean hundreds of unrelated buttons on a page; it means keeping adjacent operations close enough that you can finish the job without assembling a temporary toolchain from five browser tabs.

You find out by choosing a tool that shows its work, because for batch jobs speed without inspection isn't actually useful. Many online converters optimize for the transaction — upload, process, download — and that shape hides exactly the thing you need to check: what changed. Real work needs a loop instead: try, inspect, adjust, and keep the original available. The more sensitive or messy the files, the more that loop belongs close to the filesystem.

A good batch flow makes the outcome obvious before you commit it to a client, an upload form, or an archive. You should be able to see which files were accepted and which were skipped, where the outputs will land, and whether the originals are preserved — and then confirm the concrete result: the final file size, the converted format, the new dimensions, or the batch summary. That visibility is what turns acting on a folder of irreplaceable material from an anxious guess into a reviewable step.

This is where the transaction model of most "compress image" web tools feels weakest. They hand you a download and assume it's correct; if the free tier quietly degraded the output or dropped a file, you discover it later, in front of the client. A local batch tool that previews the change and leaves the source untouched lets you catch the bad run before it matters — and re-run it costs nothing because the originals are still sitting there.

That's exactly the ask showing up from Mac users: practical right-click actions on the file itself, not a separate destination you have to navigate to. The useful product surface starts before a document is even opened. If you can create, rename, move, inspect, convert, or compress from where the file already lives, the tool becomes part of the workflow instead of another tab. When every job instead moves through a different website or heavyweight suite, you end up having to remember which tool preserved metadata, which compressor damaged text, which converter added a watermark, and which upload box can be trusted — and that overhead is the actual friction, not the conversion.

The other half of this is repetition. A lot of image chores aren't one-offs; they're the same resize, the same format conversion, the same metadata-strip applied to each new batch. A local workbench is strongest when those repeated actions become saved recipes instead of a fresh tool hunt every time. The goal isn't novelty — the best file utility feels almost uneventful: open the file, choose the action, verify the output, and move on.

That's also why staying local matters here specifically. Right-click actions and saved workflows only earn trust if they don't quietly turn a small chore into a data-sharing decision. When the action runs on your machine, the shortest path from file to result is also the safest one.

The wall new photographers hit isn't editing — it's the export dialog. RAW developers like RAWTherapee and Darktable are built around a "process everything, then output" model, and the moment you have to reason about output profiles, chroma subsampling, and resize-on-export, the tool that felt powerful starts to feel like a cockpit with no labels. The edits are done; you just want files a client or a website can actually use.

Separate the two jobs and it gets simple. The RAW developer's only remaining task is to output a standard format — export your edited shots as JPEG, or TIFF if you want a high-quality intermediate, at full resolution, and don't worry about sizing there. Everything after that is plain file work, and it's the same whether you shoot RAW or not: get the format right, get the dimensions right for where the photo is going, and get the file size down so it uploads and loads quickly.

That second half is where a general converter beats fighting the editor's export panel. Web galleries, marketplaces, and email each want different maximum dimensions and file sizes, and doing that per-photo by hand across a shoot is the real time sink. Converting a whole folder in one pass — same target format, same longest-edge dimension, same quality — turns an afternoon of exporting into a couple of minutes, and it runs locally, so a 400-photo shoot never has to be uploaded anywhere first.

Browser support is one milestone, not the finish line — and it's usually the moment people over-convert. A format is ready for your files when everything your files touch can read it: the CMS that generates thumbnails, the CDN that resizes on the fly, the social platforms that unfurl previews, the OS file browser your client uses, the design tools that will open the asset in two years. JPEG XL is genuinely good — better compression than JPEG at the same quality, lossless recompression of existing JPEGs, wide-gamut support — but the surrounding ecosystem adopts years behind the browsers, and every gap becomes your support ticket.

The deeper rule: a format migration is an experiment you run on a copy, never an in-place rewrite. If you bulk-convert your originals and delete them, you've bet your archive on a format's future and thrown away the version everything currently understands. If instead you convert derivatives — the compressed copies you actually serve — you get the bandwidth win where it matters while the masters stay in boring, universally-readable formats.

So the practical answer: serve modern formats where you control the whole pipeline and can fall back (the <picture> element exists for exactly this), keep originals untouched, and revisit once the tools around you catch up. The cost of converting later is one batch job. The cost of converting too early is discovering, one broken preview at a time, which tools in your workflow still can't read the files.

The always-shoot-RAW advice quietly assumes you'll do heavy editing. RAW pays off exactly when you need what it preserves: shadow recovery, highlight rescue, white-balance fixes, large prints. If you're sharing to social, printing small, or documenting life, a modern camera JPEG is not a compromise — it's the output of a very good processing pipeline, and skipping it means you've signed up to do that pipeline's job yourself. That's also why an iPhone RAW often looks worse than the JPEG next to it: the JPEG has computational processing baked in; the RAW is a starting point that expects you to finish it. Neither file is lying — they're different stages of the same photo.

So pick by workflow, not ideology: RAW when you know you'll edit hard or print big, JPEG when the camera's rendering is the product. RAW+JPEG is a legitimate answer while you learn your own cutoff, at the cost of storage and culling time.

The second half of the problem is trust in the other direction: files you receive. "High resolution" on an invoice tells you nothing — a 2-megapixel image is roughly a 4×6-inch print at 300 DPI, whatever the filename says. Judge files by their actual pixels and metadata, not the label. Check the real dimensions before you promise anyone a wall print, and check what you're sending out too: a client asking for "the RAW files" is often asking for something your contract should define, because source files and finished deliverables are different products.

More than you'd expect, and less than you need. Sorting the two saves an argument.

What comes out cleanly. Embedded raster images extract at their original resolution — usually the photography, often the largest asset in the layout. Text extracts as text, so you can pull the copy without retyping it. And any page or region can be rendered at high DPI, which gives you a usable still of the whole composition or of any element sitting on its own background.

What doesn't. Editable layers, the layout as separate objects, and the fonts. A PDF may embed a font subset — enough to render the glyphs used, not enough to practically or legally set new text in it. Vector artwork is stored as drawing instructions, so a logo may survive as paths but arrives as anonymous shapes without the naming, grouping, or live effects that made it editable. Anything flattened into the background is genuinely gone as a separate object; a high-DPI render and a manual cutout is the honest answer there.

For video specifically: extract the embedded photography at full resolution, render the page at 300–600 DPI for anything you need to cut out, pull the text so titles can be re-typeset in your own project, and identify the typeface so you can license or substitute it deliberately rather than by eye.

Then fix the actual problem, which is the handoff. A deliverable list agreed before the work starts — layered source file, logo as vector, fonts named, photography as originals — costs one line in the brief and saves this reconstruction every time. Asking for source files after a flattened PDF has already been sent is a much harder conversation than asking up front.

Two separate problems are tangled together, and the first one is not about software.

GIF does not have transparency in the sense you mean. Its transparency is one bit per pixel — a single palette index declared invisible. A pixel is fully there or fully gone, with nothing in between. Your PNGs almost certainly have an 8-bit alpha channel with hundreds of partially transparent edge pixels, and those have to be resolved to on or off. That is the halo people complain about: soft edges become hard, and antialiasing that was blended against nothing gets blended against whatever the encoder assumed. GIF also caps out at 256 colours per frame, so gradients band.

If that is unacceptable, the format is the problem and no tool fixes it. Animated WebP and APNG both carry a real alpha channel, and both are supported by every current browser. Choose GIF only when the destination genuinely requires GIF — some chat platforms, some ad systems, some legacy CMSes still do.

If it must be GIF, control the parts that determine quality:

• Matte deliberately. Pick the background colour the edges will be blended against and make it match where the GIF will sit. Getting this wrong is what produces a white or grey fringe on a dark page.
• Set one alpha threshold for the whole sequence. Per-frame decisions make edges shimmer.
• Build one palette across all frames, not per frame, or colours drift as it loops.
• Normalise the frames first. Identical dimensions, consistent ordering by zero-padded filename, and a decided frame duration. Most "the tool won't accept my folder" problems are actually inconsistent input.

The reason desktop tools want a video is that video is a defined sequence with a frame rate, whereas a folder is not — the ordering and timing are conventions the tool has to guess at. Which is also why the reliable local route is: normalise the frames, assemble them into a sequence, then encode once with the settings above.

"300 DPI" is not a property of an image on its own — it is a ratio between pixels and a physical size. A canvas is 3000 × 3000 pixels; whether that is 300 DPI depends entirely on how big you print it. At 10 inches it is 300 DPI, at 20 inches it is 150. So the printer is not disputing your settings, they are telling you the pixel count does not support the physical dimensions.

Work it out directly: required pixels = final inches × 300. A 24-inch banner at 300 DPI needs 7200 pixels across. Check what you actually have before anything else, because it determines which of the following applies.

If the artwork is short of that, there are three honest routes:

• Redraw at the required size. For a logo this is the right answer and usually faster than expected — a logo is a small number of deliberate shapes, and it will be needed as a vector eventually anyway. Everything else is a workaround.
• Trace it, selectively. Vectorisation works on hard-edged flat shapes and fails on texture, soft brushwork, and gradients. A Procreate logo is often a mix, so trace what suits it and leave the rest. Nothing is invented — a trace can only interpret edges that are already legible in the pixels.
• Rebuild the type. Never trace text if you can identify the typeface. Traced letterforms carry every pixel artefact into the vector and cannot be re-spaced or re-set.

A few things worth knowing before you send anything:

• Upscaling adds pixels, not information. AI upscalers are convincing on screen and produce plausible invented detail; at 24 inches, viewed close, that detail is visibly wrong. For a logo, where the shapes are the identity, invented edges are a real risk.
• Large-format viewing distance changes the rules. Banners are routinely produced at 100–150 DPI because nobody stands a foot away. Ask the printer what they actually need for the size and distance before assuming 300.
• Export with explicit physical dimensions, and proof at final size — printed on paper, taped up, viewed from where people will stand. Screen proofing at 12% zoom hides everything that matters.

The general rule: decide the largest physical size first, then create at it. Raster artwork carries its ceiling with it forever.