In 1998, a small company whose name was still synonymous with a search engine itself left its logo work in an XCF file. GIMP's official team cites the fact that this file still opens looking the same in the current version as proof of compatibility.
When a work file format keeps using the same container for decades, the tools inside multiply while the shape of the container stays as it was back then. For a long time, GIMP's unit of work has been XCF, a single binary that packs together layers, selections, paths, and guides. The name comes from the eXperimental Computing Facility at the University of California, Berkeley, and it was first released on December 15, 1997.
The Burden Carried by a Binary Work File
XCF writes GIMP's internal state to disk almost as-is. The developers themselves have never recommended it as an exchange format. Whenever the internal structure changes, the file format is tweaked accordingly, making it hard for other software to keep up. There was an effort to consider OpenRaster—an OpenDocument-style shared raster proposal—together with the Krita side, but its adoption remained limited.
Compression, too, evolved in stages. In versions before GIMP 2.10.0 (April 27, 2018), pixel data was mainly RLE (run-length encoded), and it often relied on external compression such as gzip, bzip2, or xz. From version 4 onward, zlib became available as well. Even so, the container itself was never designed to let you read "just the chunk you need" from a huge project.
What maintainer Jehan has been focusing on over these past few months is rebuilding that very container. The official development report dated August 16, 2026 states clearly that XCF has been the primary format since 1997, and notes that it doesn't handle large, complex projects well—especially the multi-page and animation features planned for GIMP 3.6. The new format will take the common "zipped XML" structure—XML packed inside a ZIP. The details are still in the design and implementation stage, but the team explains that at save time, it will be possible to update only the changed portions rather than the entire file, which would also make auto-save practical.
On the developer-facing roadmap, the "New XCF format" entry is marked as Discussed, with a note that an archive-based format would allow reading only the needed data later on, making it easier to handle large projects like pages and animations. The Auto-save entry is marked No, with a note that it depends on the new format and the GEGL buffer (where pixel data is stored within the GEGL image-processing library). In other words, auto-save is a downstream task that comes after the file format work.
XCF isn't going away. Future versions of GIMP will continue to support reading existing XCF files. However, once the new format is finalized, the policy is to add saving and loading support for new features only to the new format. Old files will still open, but new capabilities will only live in the new container. Neowin (August 17, 2026) summarized this by saying XCF will step back into a compatibility role, while future features move to a separate format. The official name for the new format has not yet appeared even in the official report.
| Item | Current XCF | New Format Under Design |
|---|---|---|
| Introduced | 1997 (first public release December 15 of that year) | Under design and implementation as of August 2026 |
| Structure | Binary close to GIMP's internal state | XML packed inside a ZIP |
| Saving | Tends to require rewriting the entire file | Aims to update only changed portions |
| Large projects | Officially noted as unfavorable for multi-page and animation | Foundation for pages and animation planned for 3.6 |
| Auto-save | Not yet started per roadmap (format-dependent) | Officially described as easier to achieve |
| Compatibility | Legacy XCF will continue to be readable | Saving of new features limited to new format once finalized |
This parallels why office documents moved to OOXML and ODF, where the content is XML and the outer shell is ZIP: it's easier to track differences as text, and you don't have to rewrite an entire huge binary every single time. What GIMP is after is that structural advantage, not novelty for its own sake.
A Foundation for Both Editing and Interchange Progressing in Parallel on the 3.4 Series
The new format isn't the only thing in the August report. The features covered are slated for the development series GIMP 3.3.2, while the team wrote that the stable version 3.2.6 will focus on bug fixes over the coming weeks. An official development release of 3.3.2 hasn't come out yet, and the team is directing people to check it early via nightly builds.
On the non-destructive editing front (a method of stacking filters without finalizing pixels), Alx Sa made it possible to apply non-destructive filters to layer masks. Reju fixed the filter popover, allowing live effects on layers and masks to be handled within the same view. In the gradient tool, turning on "Editable Gradient" now puts it into the filter stack, allowing you to toggle visibility, reorder, delete, and re-edit it. Filters without dialogs, such as Invert, can now be applied non-destructively even to non-raster layers like groups, links, text, and vectors.
The work around Adobe Photoshop's PSD format was extensive enough to warrant its own section. Frank Teklote added export steps for PSD metadata targeting TIFF and JPEG, complementing existing import support. Now, JPEGs with paths or TIFFs with layers created in GIMP retain that information on export. Jacob Boerema implemented reading of PSD Descriptor (a relatively under-documented text format not fully covered by the public specification updated in 2019). As a result, text layers become editable, some adjustment layers and newer layer styles show up as GEGL equivalents, and solid-color shapes come in as vector layers. GSoC (Google Summer of Code) participants Akascape and Waris Maqbool are also working in this area.
For MyPaint brushes, Cassidie Grogan added Spectral Blending. This simulates a more pigment-like mixing behavior, where yellow and blue lean toward green rather than dark yellow, and red and yellow become orange. Intensity is controlled via the Pigment slider. Michael Natterer fixed brush previews to display at actual size instead of a fixed 48x48 pixels, reducing blurriness on large displays.
On the UI side, Denis Rangelov unified the layer lock icons and converted all 78 cursors to SVG, reducing jagged edges even at high resolution. woot000 addressed an issue where the checkered transparency pattern was rotating along with the canvas rotation, causing heavy rendering and zoom performance; now the pattern no longer rotates. A bug where the checkered pattern disappeared beyond a certain zoom level was also fixed. Alx Sa has begun moving GIMP away from GTK's built-in file chooser toward each platform's native dialog—Windows, macOS, KDE, and so on. Simple dialogs are done, but ones with more features still need their workflow redesigned.
On the security front, Jacob Boerema and Alx Sa patched reported issues in some image plugins. Waris Maqbool's Sharpen has been merged into GEGL and will be included in the next GEGL release. Dimitriy Ryazantcev brought Windows ICO, CUR, and ANI reading closer to spec and fixed the rendering of 32-bit ICOs.
Phoronix (August 16, 2026) briefly reported that, about 30 years after XCF, a new format is now in sight; that ZIP+XML will make large multi-page projects and auto-save easier to handle; and that XCF compatibility will be maintained.
Implementation Gaps That Remain Even Once the Format Is Decided
The official team keeps repeating that "the technical details are still being designed and implemented." The August text doesn't reveal the file extension, MIME type, where the GEGL buffer will sit inside the archive, or how partial writes during a crash will be closed off. Since auto-save is marked No on the roadmap, the skeleton of the new format comes first, and productizing periodic saves comes later.
The position of third-party tools will also change. As Wikipedia lists, Krita, ImageMagick, MediaWiki, and various viewers have all partially supported reading XCF. There have long been cases where indexed color, multiple layers, or a new version number cause crashes. Developer documentation notes that XCF files from GIMP 3.0.0 (March 16, 2025) onward are version 15, and there have been past cases where files saved in a development version triggered an "unsupported XCF file version" error when opened in the stable version. If the new format is ZIP+XML, it should be easier to peek inside, but other software will have a hard time implementing support until the spec is finalized. The relationship with OpenRaster isn't mentioned in this official report either.
The fact that a 1998 logo XCF still looks the same today speaks to the strength of read compatibility. The decision to freeze the write side is, in a sense, a trade-off made to preserve that strength. If new features kept getting bolted onto the old container, the version number would keep climbing, and older GIMP versions and external readers would keep getting left behind.
What remains untested is scale. Multi-page support and core animation are work-in-progress for 3.6, and the official team writes that the new format is the premise for that. How many pages, how many frames, and how many gigabytes partial updates can handle isn't addressed yet, either in 3.3.2 or in the stable release. Anyone who runs into a broken archive on a nightly build will end up testing that history of compatibility on their own work files. Whether the pixels and history inside can safely come back after switching containers is something that will only be determined through future implementation and real-world testing.