Formats & roadmap

Drop anything. There is no file-type filter: every file you add gets a real decode attempt, and if it can't be read you get a plain error saying so rather than the file silently vanishing from the list.

PNG, WebP, GIF, TIFF, ICO, TGA and QOI keep transparency; JPEG, BMP and PPM flatten transparent areas to white. Quality only applies to the lossy formats (JPEG, WebP, AVIF). GIF builds its own palette from your image with a median-cut algorithm — use 256 colours for the best result, or drop to 32 for a much smaller file. QOI and TIFF are fully lossless, so opaque pixels come back bit-for-bit identical. Animated GIFs convert their first frame only. ICO output builds a standard multi-resolution favicon (16×16, 32×32, 48×48), stretching a non-square source to fit each square size rather than cropping it — start from a square image for best results. AVIF output only appears if your specific browser can actually encode it; support is inconsistent, so we feature-detect rather than offer something that would silently fail.

Why so many hand-written formats: browsers can only encode PNG, JPEG and WebP. Ask a browser canvas for a GIF or a TIFF and it quietly hands back a PNG instead. Every other format here is written byte by byte in JavaScript on your device, which is how they stay available without uploading anything.

Not supported, and why: HEIC/HEIF and RAW camera formats (CR2, NEF, ARW, DNG…) aren't decodable by any browser without a large external library, so we don't fake support for them. SVG conversion only works one direction (SVG → raster) — going the other way is image tracing/vectorization, a fundamentally different (and lossy) problem, not format encoding.

Video files work here. Your browser's audio decoder reads the audio track out of MP4, MOV, MKV and WebM just as happily as it reads an MP3, so those files convert like any other — a straightforward way to get the soundtrack out of a video without uploading it anywhere. Input support otherwise depends on your browser's codecs (all major browsers handle MP3, AAC/M4A and WAV; OGG and FLAC support varies).

WAV is written at 8, 16 or 24-bit PCM or 32-bit float — 16-bit is the safe default, 24-bit and float are for further editing, and 8-bit is small and deliberately lo-fi. FLAC is fully lossless and typically lands around half the size of the equivalent WAV; it's encoded here from scratch in JavaScript using fixed predictors and Rice coding. AIFF (big-endian PCM) and AU are there for older Mac and Unix audio tooling. Opus is the smallest option and uses your browser's own encoder, so it only appears where that encoder exists.

No MP3 output, deliberately: no browser exposes an MP3 encoder, and shipping one would mean downloading a large codec library to your device. FLAC (lossless) and Opus (smaller than MP3 at the same quality) both cover the ground MP3 usually gets used for. MP3 files are perfectly fine as input.

Images → PDF embeds each image directly into a standard PDF (one page per image, in the order you add them). Text, Markdown and Word → PDF typesets with the standard PDF fonts (Helvetica and Courier), so the result opens anywhere without embedding a font file; headings, bullet and numbered lists, block quotes and fenced code blocks are laid out, and pages break automatically.

What Word conversion does and doesn't do: a .docx is a ZIP of XML, so we read the document text, heading levels, lists and tables straight out of it. Inline formatting (bold, italics, colour), images, headers/footers and footnotes are not carried across — this converts the writing, not the layout. Older .doc files are a different, binary format and aren't supported. PDF → Word isn't offered either: that's document reconstruction, a much harder problem than format conversion, and we'd rather not pretend otherwise. Looking to write or edit a document instead? The Documents editor is a separate tool.

The input format is detected from the file, so you only pick an output. Everything is normalised to a list of flat records: the first row of a CSV/TSV becomes the column names, JSON expects an array of objects (a single object, or an object of equal-length arrays, also works), and XML uses its repeated element as the row. Nested values are kept as JSON text rather than silently dropped.

Excel specifics: reading an .xlsx converts every worksheet (one output file per sheet), resolves shared strings, uses the cached result of formula cells, and converts date-formatted cells into readable dates instead of the raw serial numbers Excel stores. Writing an .xlsx keeps digit strings such as 007 or a 20-digit ID as text, so they don't get silently rounded into numbers. Legacy .xls is a different binary format and isn't supported.

ZIP support uses the compression built into modern browsers, so there's no library to download and nothing to upload. Each file is deflate-compressed, or stored uncompressed when that would actually be smaller. Reading works on stored and deflated entries, including UTF-8 file names; entries are only decompressed when you download them, so listing a large archive stays cheap. Encrypted (password-protected) ZIPs and ZIP64 archives over 4 GB aren't supported, and neither are .rar or .7z, which are separate proprietary formats.

Direction is detected from the file itself — a WEBVTT signature wins over the extension. Going to SRT, cues are renumbered from 1, timestamps switch from . to ,, and VTT-only features with no SRT equivalent (cue settings, NOTE/STYLE blocks, voice and formatting tags) are stripped rather than left to confuse a player. Back to the converter →

Why there's no big download. The usual way to convert video in a browser is to ship a WebAssembly build of ffmpeg — around 32 MB, which is roughly 700 times the weight of this entire app, and every visitor would pay for it whether or not they ever converted a video. Instead this uses the video encoders already built into your browser, so adding video conversion added nothing to what the page downloads.

Why it runs at normal speed. Conversion plays the clip through once, so a two-minute video takes about two minutes. That's deliberate. Playing the file faster doesn't make the browser work harder, it makes it skip frames: on a ten-second 30 fps test clip we kept all 300 frames at normal speed, but only 253 at double speed, 151 at quadruple, and 40 at sixteen times. Since "faster" really means "throw frames away", quality is controlled with the bitrate and resolution settings instead, and every frame is kept. Leave the tab visible while it runs.

Resolution only ever scales down. Choosing a size larger than the source leaves the video untouched rather than upscaling it, since upscaling invents detail and inflates the file for nothing. The number refers to the short side, so a portrait clip converted at 720 comes out 720 wide, not 720 tall.

Format notes. WebM (VP9) gives the best quality per byte and is the default. MP4 uses H.264 video for maximum compatibility, but its audio is Opus, not AAC, because no browser exposes an AAC encoder — most current players handle that fine, though some older ones will play the picture without sound. If you need guaranteed-everywhere audio, choose WebM. Animated GIF steps through the video frame by frame rather than playing it, is capped at 300 frames, and has no sound — GIF has no audio track at all.

Not supported: trimming and cropping (this converts whole files), subtitles burned into the picture, and any codec your browser can't already play — if the file won't play in a browser tab, it won't convert here either. To pull just the soundtrack out of a video, use the Audio section instead; it reads the audio track directly and is much faster than a full re-encode.

A photo from a phone routinely records where it was taken to within a few metres, which camera took it, its serial number, and when. None of that is visible when you look at the picture, and most places you upload a photo do not remove it for you. Scanning shows you the actual values; the location, camera and author rows are highlighted because those are the ones that identify you.

Why removal here is lossless. Re-saving a photo in an image editor drops the metadata but also re-compresses the picture, losing a little quality every time. This cuts the metadata segments out of the file and copies the compressed image data across byte for byte, so the result is visually identical to the original — verified by decoding both and comparing every pixel. Colour profiles are deliberately kept, since removing those would change how the image looks.

Scope: JPEG, PNG and WebP. Converting an image in the Images tab also drops metadata as a side effect, but that path re-encodes the pixels — use this tab when you want the original file, minus the metadata.

Text files carry no reliable record of how they were encoded, which is why an old CSV or subtitle file so often opens as é or a row of �. Pick the encoding the file was saved in and you get clean UTF-8 back. The decoders come from the browser itself, so there is nothing to download and the list covers the Western, Central European, Cyrillic, Greek, Turkish, Arabic, Hebrew, Thai, Japanese, Korean and Chinese legacy encodings. Automatic detection tries UTF-8 first and falls back to Windows-1252, which is right most of the time but is a guess — if the result still looks wrong, pick the encoding explicitly.

Base64 and hex both work in either direction and decide which one you want from the content, not the file name. Base64 accepts wrapped lines, data: URLs and the URL-safe alphabet; the hex tool reads back its own dumps as well as bare hex strings.

Each page is rendered at the resolution you choose — 72 dpi for screens, 150 for general use, 300 for print — and saved as a JPG, PNG or WebP. A multi-page document also comes back as a single ZIP with the pages numbered so they sort correctly. Pages are painted onto white first, because PDF pages are transparent and JPEG has no transparency, so skipping that step would hand you black rectangles.

This is the one part of the site that downloads a library, and it is worth being straight about it. Rendering a PDF faithfully — fonts, vector paths, colour spaces, scanned image codecs — is a genuinely large problem, and there is no browser API for it. So this tool uses Mozilla's pdf.js. Two deliberate decisions follow from that:

It is never fetched unless you use it. Nothing is downloaded when you open this site, browse the other tools, or even extract the text from a PDF — that runs on our own code. The renderer is only requested at the moment you convert a PDF to images, so everyone else pays nothing for it. There is an automated test asserting exactly this, so it cannot quietly regress.

It is served from this site, not a CDN. Loading it from someone else's server would tell that third party you had just opened a PDF, which is precisely the thing this site exists not to do. Your file itself still never leaves the device either way. pdf.js is Apache-2.0 licensed; the licence ships alongside it.

Limits: very large pages are capped so a long document cannot exhaust your device's memory, and documents beyond 500 pages are rendered up to that point and say so. Going the other way — images back into a PDF — is the first tool on this page, and needs no download at all.