> For the complete documentation index, see [llms.txt](https://docs.realmacsoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.realmacsoftware.com/squash/quick-guide/nodes/format.md). # Format Choose an output format and compression settings, and understand the trade-offs Format chooses the file type and compression settings for your exported images. This section is always available, and its settings are remembered between launches. The smallest useful file is one that still looks right for its intended use. Results depend on the original image, its dimensions, the output format and the settings you choose. Squash shows the result in the image list and the [preview](/squash/quick-guide/editor.md) so you can decide before exporting. ### Export formats | Format | Extension | Controls in Squash | | ------- | --------- | ------------------------------------------------------------------------ | | JPEG | `.jpg` | Quality and Progressive. | | PNG | `.png` | oxipng (default), Crush, Zopfli, Standard or pngquant (lossy) algorithm. | | TIFF | `.tiff` | Standard TIFF output. | | HEIC | `.heic` | Quality. | | WebP | `.webp` | Lossy or Lossless mode, with Quality or Compression. | | AVIF | `.avif` | Quality and Effort. | | JPEG XL | `.jxl` | Quality. | Squash exports still images. It does not export animated GIFs or preserve editable layers and vector artwork. JPEG does not support transparency; choose a format and receiving app that support it when you need it, and check the exported result. ### Import formats Squash opens the image types your version of macOS can decode. Common inputs include **JPEG, PNG, TIFF and HEIC/HEIF**, as well as supported RAW, DNG, PSD and GIF files. Support for specialist files depends on macOS and the particular file. Test a sample from your camera or design app before processing a large batch. A file being recognised as an image does not guarantee that its contents can be decoded. ### Choosing a format * **JPEG** is a good starting point for photos that need broad compatibility. * **PNG** suits screenshots, graphics and images with transparent areas. It is also useful for photos when lossless pixels matter, but files can be large. * **WebP** and **AVIF** are good choices for web images when your website supports them. * **HEIC**, **TIFF** and **JPEG XL** can suit other workflows. Check what your receiving apps or services accept before converting a batch. For photos, re-encoding an already compressed JPEG can add visible artefacts, so work from the best original you have. For graphics, screenshots and transparent images, compare the PNG algorithms with WebP Lossless. Metadata is handled separately from the format. See [Metadata](/squash/quick-guide/nodes/metadata.md) for what each format can keep. ### Quality and compression **Lossy compression** changes pixel information to reduce file size. JPEG, HEIC, WebP, AVIF and JPEG XL have a quality slider: lower values usually produce smaller files with more visible changes, and higher values favour image quality. A quality percentage means something different for each format. JPEG at 70% and WebP at 70% will not necessarily look the same or produce the same file size. **Lossless compression** preserves the processed image's pixels. The oxipng, Crush, Zopfli and Standard PNG algorithms are lossless, and WebP has a Lossless mode. Resizing, effects and watermarks still change the image before it is encoded; lossless compression doesn't undo them. ### JPEG Select the **Progressive** checkbox to create a JPEG that can appear in progressively sharper passes as it loads in software that supports this display mode. ### PNG algorithms | Algorithm | What to expect | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------ | | oxipng (default) | Lossless optimisation that gets very close to Zopfli's file sizes in a fraction of the time. The best choice for most batches. | | Crush | Lossless optimisation. Faster than Zopfli, but usually gives noticeably larger files than oxipng or Zopfli. | | Zopfli | The most thorough lossless optimisation. Files can be slightly smaller than oxipng, but processing takes much longer. | | Standard | Normal lossless PNG encoding, with no additional optimisation pass. Fastest, but the largest files. | | pngquant (lossy) | Reduce the image to at most 256 colours. This changes pixel colours and can give much smaller files. | oxipng, Crush, Zopfli and Standard are all lossless: the exported pixels are identical, and only the file size and processing time differ. #### How the lossless options compare In our tests on a batch of nine PNG images: | Algorithm | Total size | Time | | --------- | ---------- | ----------- | | Zopfli | 8.81 MB | 187 seconds | | oxipng | 8.88 MB | 7 seconds | | Crush | 9.57 MB | 42 seconds | oxipng came out only 0.5% larger than Zopfli overall while running about 26 times faster. Crush was slower than oxipng and produced larger files. Choose Zopfli when the last fraction of a percent matters more than export time, such as a small set of images for a website you will serve many times. Results depend on the images, so treat these figures as a guide rather than a guarantee. Click the **info** button beside the Algorithm menu for a short description of the selected algorithm. PNG optimisation is applied during export. ### WebP Choose **Lossy** for quality-controlled compression, or **Lossless** to preserve the processed image's pixels. In Lossless mode, the slider is labelled **Compression** rather than Quality. ### AVIF AVIF offers **Quality** and **Effort** controls. Effort is used by the encoders that support it; the result and processing time depend on the encoder available on your Mac. ### JPEG XL JPEG XL uses the `.jxl` extension and offers a quality slider. Check that the apps or services receiving your files support it. JPEG XL exports keep the EXIF metadata you choose to keep in [Metadata](/squash/quick-guide/nodes/metadata.md), and the title, description, keywords, creator, copyright and website it writes, but not other IPTC or XMP metadata. ### Colour Squash converts every export to **sRGB**, whichever format you choose. sRGB is the standard colour space for the web and displays correctly in browsers, apps and on most screens. If an image uses a wider colour space, such as Display P3 or Adobe RGB, its most saturated colours are brought into the sRGB range, so very vivid reds, greens and oranges may look slightly less intense. The [Metadata](/squash/quick-guide/nodes/metadata.md) settings don't change this. ### Why a file can get bigger An already optimised image may have little left to save. Converting it to another format, choosing a higher quality or adding an effect can produce a larger file than the original. Squash still exports a larger result if you choose to export it; it does not keep the original file instead. In the image list, a compressed size larger than the original is shown in red. You can also compare the Before and After sizes in the [preview](/squash/quick-guide/editor.md). If an output is larger than the original, lower the quality, resize the image or try another format. ### A practical workflow 1. Decide which format your website, app or recipient needs. 2. Resize to the dimensions the image will actually be displayed at. Use **Max Size** in [Resize](/squash/quick-guide/nodes/resize.md) to avoid enlarging smaller images. Halving the width and height leaves a quarter of the pixels, which can make a substantial difference to file size. 3. Adjust quality in small steps, checking fine detail and text in the preview. 4. Compare the file sizes in the image list. Squash recalculates them automatically when you change settings, unless you have turned off **Automatically compress images** in [Settings](/squash/quick-guide/preferences.md); in that case choose **File → Squash**. 5. Export when both the appearance and file size suit your needs. Changing the format doesn't save files to your destination until you export. ### JPEG XL vs AVIF for web images Jake Archibald's [JPEG XL vs AVIF for web use-cases](https://jakearchibald.com/2026/jpeg-xl-vs-avif/) (15 October 2026) compares file size, visual quality and processing speed. His main findings: * **Web photos:** AVIF usually produced smaller files at comparable visual quality. At default encoder effort, the best JPEG XL results were typically 15–25% larger, with exceptions for some images. * **Graphics and transparency:** AVIF's advantage was stronger for screenshots, illustrations and transparent images. * **Lossless images:** JPEG XL led for lossless photos and could shrink existing JPEGs without further quality loss through dedicated JPEG recompression. * **Speed and settings:** AVIF generally decoded faster. Encoder choice and effort affected file size, processing time and memory use; higher effort did not always help. His recommendation for web delivery is AVIF with full colour resolution (4:4:4), then trying JPEG XL when AVIF produces an unusually large file. The article tests specific encoders and includes modes Squash does not expose, such as JPEG recompression, so its percentages are not measurements of Squash. Compare your own exports in the preview. ### Learn more about JPEG {% embed url="" %} How does .jpeg work? {% endembed %}
Squash 3 reference screenshots These screenshots show the earlier Squash 3 interface. ![](https://1309898043-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hJwt9oZ5CYj9I9YIUa9%2Fuploads%2Fgit-blob-8e42597cff4713383302542d25f37d6ef4a274e0%2FCleanShot%202022-04-05%20at%202.57.09%402x.png?alt=media)
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.realmacsoftware.com/squash/quick-guide/nodes/format.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.