For nearly three decades, XCF has been the internal language of GIMP — the format that holds layers, paths, channels, and edit history between sessions. It was never designed to be portable or shared; it was a working format, deliberately opaque to outside software. That posture made sense in 1995, when GIMP was a graduate project and the editing landscape was radically different. What’s changed with GIMP 3.4 is that the project has reconsidered some of those assumptions, and the consequences for anyone maintaining a library of XCF files are worth thinking through carefully.
What XCF Actually Is — and Why It Stayed So Proprietary for So Long
XCF stands for eXperimental Computing Facility, which was the name of the lab at UC Berkeley where GIMP originated. The format reflects that origin: it was never submitted to a standards body, never assigned a public specification in the way PNG or TIFF were, and its internal structure evolved with GIMP’s own codebase rather than through external consensus. Each version of GIMP that changed the format incremented an internal XCF version number (the file header stores this as a plain ASCII string — “gimp xcf v011” for version 11, for example), which is how GIMP itself knows whether it can parse a given file.
What XCF stores is comprehensive. A saved XCF file holds full layer stacks with individual opacity, blend mode, and visibility states; channel masks; path data as vectors rather than rasterized pixels; guides and grids; and since relatively recent versions, layer groups. The compression used for pixel data within XCF has historically been RLE (run-length encoding) at the tile level, though GIMP has also offered zlib-based compression as an option for years. None of this is exotic — but because the format specification lived primarily in the GIMP source code rather than a publicly maintained document, third-party support remained thin. Most other editing applications treat XCF as read-only at best, or simply don’t support it.
What Changed in GIMP 3.4
The 3.4 release, which introduced what the project describes as a new project file approach, represents the most significant rethinking of how GIMP handles its native format in the application’s history. The practical changes fall into a few distinct categories.
The format version increments again. New files saved in GIMP 3.4 use a higher internal XCF version that older GIMP builds won’t recognize cleanly. This is consistent with past behavior — GIMP has always bumped the version when it adds features that the file needs to encode — but the 3.4 changes are more extensive than minor feature additions.
PSD compatibility improved substantially. GIMP 3.4 ships with reworked Photoshop PSD import and export, which is a separate thing from XCF itself but is directly relevant to anyone whose workflow crosses between GIMP and Photoshop-ecosystem tools. Layer effects, text layers, and certain adjustment-adjacent structures now round-trip more faithfully than they did in earlier versions. The details of that change are covered in our article on GIMP 3.4’s new project file format and PSD support.
The relationship between working file and export is more explicitly separated. GIMP has enforced a distinction between “export” (producing a flattened JPEG, PNG, or TIFF) and “overwrite/save” (writing an XCF) since GIMP 2.8. In 3.4, this separation is reinforced at the interface level, making the project-file model — work in XCF, export when you need a deliverable — harder to accidentally bypass. That’s a workflow philosophy, not just a format change, but it shapes how migration should be approached.
Migration Scenarios: What You Actually Need to Worry About
If your entire GIMP workflow is self-contained — you open files in GIMP, save XCF, export PNG or JPEG for delivery — the format change matters mainly in one direction: old XCF files open in GIMP 3.4 without issue (GIMP has always maintained backward read compatibility), but files saved in 3.4’s newer format version won’t open correctly in significantly older GIMP builds. If colleagues or collaborators are still running GIMP 2.10, for instance, sharing working XCF files becomes complicated.
The practical options here are limited but clear:
- Export a flattened intermediate — If you need someone on an older GIMP version to review or continue work, export to a format that preserves as much as possible: TIFF with layers if they have a GIMP version that supports it, or a PSD if they’re moving to another editor entirely.
- Coordinate version upgrades — If a team is sharing XCF files, everyone should be on a compatible GIMP version. GIMP is free software; the barrier to upgrading is low.
- Archive in an open format — For long-term storage, XCF is not a strong archival choice precisely because its specification is application-internal. For archival purposes, exporting to TIFF (which stores layers as separate image data) or PNG (for flattened work) gives you something more durably readable. The question of what makes a format genuinely archival-grade is broader than any one application’s choices — see our coverage on file format sustainability and digital preservation for the longer context.
Compatibility With Third-Party Software
Support for XCF outside GIMP has historically been minimal, and that remains the situation. GIMP’s own libgimp and the separate libgimpformat library allow programmatic XCF access, and a handful of Linux-ecosystem tools (Inkscape has had partial XCF import at various points, and some file managers generate thumbnails using GIMP’s thumbnailer) can interpret XCF. Imagemagick includes XCF reading support, though it flattens the layer stack on import rather than preserving it.
What none of these tools handle well is the newer XCF version introduced in 3.4. Third-party support tends to lag format version increments by a significant margin, because those tools are parsing a format whose spec is effectively the GIMP source code. If your pipeline depends on Imagemagick or a similar tool reading XCF files, test explicitly with files saved in 3.4 before committing to that workflow. Browser compatibility with XCF is essentially nonexistent — this is a format that was never meant for the web, and that hasn’t changed.
The Bigger Picture: XCF as a Working Format, Not a Delivery Format
The 29-year history of XCF illustrates something that applies to proprietary working formats generally: they accumulate version debt. Each capability added to an application — layer effects, high-bit-depth color, HDR tone mapping — either gets encoded into the format or forces a parallel export pipeline. GIMP has managed this by incrementing the internal version, which is functionally correct but means the format’s long-term readability is tied to GIMP’s own longevity and backward-compatibility commitments.
For photographers and image editors, the lesson from GIMP’s format evolution is the same lesson that applies to PSD, to Lightroom’s catalog format, to any application-native project file: treat the working format as ephemeral infrastructure, not as archival storage. The XCF holds your work-in-progress; the exported PNG, TIFF, or PSD is what travels.
GIMP 3.4’s improvements to PSD interoperability make that export path more reliable than it was, and that’s the most practically useful change in the release for anyone whose files occasionally need to cross into other tools. If you want the deeper look at what those PSD changes mean for editing workflows specifically, the article on GIMP 3.4’s new PSD support walks through the layer-level specifics.
What to Do Before You Upgrade
If you’re moving an existing XCF library to GIMP 3.4, the sequence worth following is straightforward:
- Open a representative sample of older XCF files in 3.4 and check that layer structure, masks, and paths loaded as expected. Visual inspection matters here — automated round-trip testing won’t catch a silently dropped channel mask.
- If any files will need to be opened by users on older GIMP versions after your upgrade, save a PSD or TIFF copy of the layer structure before converting to the new XCF version.
- For files older than GIMP 2.6, check the header version string before assuming compatibility. GIMP’s changelog documents which version introduced which XCF version number, and that’s the most reliable reference for what a given build can actually parse.
- Don’t assume Imagemagick or other third-party XCF parsers have updated to handle 3.4 format files — verify against the current release of whichever tool your pipeline depends on.
The format change is not disruptive for most individual users, but it’s the kind of thing that causes quiet problems in shared workflows or archival contexts if it isn’t accounted for before the fact.