New in version 0.1.34
Version 0.1.34 · Apple Silicon · macOS 14 or newer
Preparing images for a website usually means uploading them to a service or wiring up a build step. Web Export does the same work in the app, on your Mac: several widths and formats in one pass, filenames that read as URLs, sRGB colour, rights metadata, a link preview, and markup you can paste straight into a page as HTML or JSX.
One pass, several widths
Give a list of widths — 400, 800, 1200, 1600 — and each source produces one file per width in a single pass. The resize mode you already chose decides what each width means, so Fill & Crop keeps a consistent shape across the whole set.
Widths above a given image’s own size are skipped rather than upscaled, so a small photo does not become four copies of itself under four different names. An image narrower than every width still produces one file at its own size.
Filename patterns can include the output width and height, so cafe-sign-400.jpg really is 400 pixels wide — measured after cropping and rotation, not copied from the number you typed.
A browser picks which file to download before the page has a layout, so it can only go by what the markup says. Choose full width, half, a third, a quarter or a fixed column, and the sizes attribute is written for you. It matters more than it sounds: telling a browser an image fills the screen when it occupies a third of it makes the browser fetch the largest file every time, and a ladder of widths then saves nothing at all.
Smaller, without a fallback problem
Write each image in more than one format in a single pass. The format you already chose stays the one every browser can read; AVIF and WebP are offered ahead of it for the browsers that understand them, which is most of them.
The markup is a <picture> element listing each format with its media type, most efficient first. A browser takes the first one it understands and never downloads the others. No detection script, no server rules, no separate build.
AVIF requires macOS 26 to write, so the option is disabled on earlier versions and says why, rather than failing partway through a batch. The generated markup follows suit: a set produced without AVIF offers WebP and the fallback, and is correct as it stands.
Readable URLs
Lowercase, hyphenated, ASCII. Camera prefixes and their frame numbers are treated as one unit, so IMG_4821 Café Sign.jpg becomes cafe-sign.jpg — not 4821-cafe-sign.jpg. A file named only IMG_4821 keeps its number, because nothing else remains.
Accents lose their diacritics, Arabic and Han romanise. A name made entirely of emoji or punctuation falls back rather than producing a file with no name at all.
Compose names from the slug, the original stem, the output width and height, and the format. The example updates as you type, so you can see the result before running anything.
Slugging makes clashes ordinary — three differently punctuated files can reduce to one name. Every filename in a batch is decided before the first file is written, so duplicates are numbered predictably instead of overwriting each other.
Correct on every screen
Output is always converted to sRGB. You can leave it untagged, which every browser reads as sRGB and which keeps files smaller, or embed an explicit profile when a pipeline expects one.
A wide-gamut source’s colour profile is never carried onto converted pixels. Version 0.1.21 fixes a case where a Display P3 WebP could come out as sRGB pixels still wearing a P3 tag, which browsers rendered over-saturated.
Credit that travels
Creator, copyright and credit are written as IPTC and mirrored into XMP. A licence page URL is written as xmpRights:WebStatement and a licensing URL as plus:Licensor — the fields image search uses to show rights information.
These describe you rather than any one photograph, so they are stored with your settings and applied to everything in a run.
A caption belongs to one photograph, so the app remembers the rule — keep what the file already has, derive from the filename, use a suggested description, or leave it empty — and never the text itself. Stamping one caption onto forty photographs would be worse than leaving them blank.
When someone shares the page
Messaging apps and social platforms render a link as a card, and the shape they want is roughly two to one — a shape nothing else in a batch produces. Web Export writes one extra image per source at that shape, as a JPEG, because scrapers are the most conservative readers of anything a site serves.
A two-to-one crop of a portrait throws away most of the frame, so the app finds the subject first and crops around it instead of the middle. Recognition runs on your Mac, and an image with no clear subject is cropped from the centre as before.
The markup carries og:image with the real dimensions of the file that was written, plus the card type — the four lines a preview needs. The preview image is kept out of the responsive set, because it is a different picture rather than a smaller one, and a browser offered it for a layout would show the wrong crop.
Ready to paste
Every source, its slug, and each file produced from it with real width, height, format and byte count — read back from the written files rather than from what was requested.
A <picture> offering each format, a complete srcset, the sizes value your layout implies, and intrinsic width and height so the page does not jump as images arrive. A path prefix lets the paths describe where the files will live rather than where they were written.
Choose the dialect and the file is written to match. This is not cosmetic: React ignores srcset and fetchpriority, so HTML pasted into a component renders, looks correct, and silently loses the responsive behaviour. The JSX version spells the attributes the way React reads them.
The first image of a batch is marked to load immediately and the rest lazily. Deferring the image a page paints largest is the most common way generated markup makes a page measure worse rather than better, so drop your hero image in first.
The credit and licensing fields are also written into the page as schema.org markup. Search engines read both this and the metadata inside the file, and page markup survives a CMS that re-encodes images on upload — which strips everything the file itself was carrying.
A tiny base64 image can be embedded in the manifest and markup, so a blurred version appears while the real file loads. No extra request, because it travels inside the HTML.
On this Mac
Image recognition runs locally and produces labels. Where a Mac has Apple’s on-device language model, those labels are phrased into something readable; where it does not, the labels are used directly. Neither stage sends anything anywhere.
Suggestions only ever repeat what was actually recognised, and images the recogniser is unsure about are left undescribed. Alt text that confidently describes something absent is worse for a screen-reader user than no alt text at all.
These are a starting point and need your review before publishing. A suggestion describes what was recognised in a picture, which is not always what matters about it — the reason an image is on a page is something only you know.
Why it matters
Responsive sizes, metadata and alt text are normally jobs for an image CDN or a build pipeline — which means your images, and your clients’ images, sitting on someone else’s servers. Every part of Web Export runs in the app. The licence and licensing URLs you enter are stored and written as text; they are never fetched. Read security & privacy details →