I just asked someone to send me a zipped psd file.

They declined, citing that zipping a file can break the fonts.

I assumed zipping a file is perfectly reversible, hence why it is commonly used. I think the other person is incorrect.

Is there any truth about zipping breaking its files' contents?

  • 53
    Maybe the other person has confused zipping a file (lossless) with jpeg compression (lossy) which can make test look ugly.
    – hookenz
    May 13 '11 at 2:54
  • I know that I once had compatibility problems for zip files, because the file format is used on all platforms...
    – jokoon
    May 13 '11 at 12:11
  • 1
    I've certainly experienced certain 'pathological' cases where both Winrar and WinXP's built-in facilities broke files (tens of thousands in a single zipfile). This was 4-5 years ago, and the only solution I could find at the time was to use 7-zip. As best I can remember, even 7-Zip couldn't successfully unzip files created by the other routines, suggesting the fault was in the zipping, not the unzipping. Obviously I opted to use 7-zip for both sides in the production system anyway. May 13 '11 at 13:51
  • 1
    @jokoon: I'm not sure it's valid to speak of a file format...used on all platforms. There are quite a few different internal formats used in zip files, and it's always possible an archive could be created by one packing routine using a format that's imperfectly supported by some other routine that you happen to use at time of unpacking. May 13 '11 at 13:55
  • @Fumble; But still, any decent archiver should catch the hash change and report the operation as a failure - not leave a broken file lying around.
    – Phoshi
    May 14 '11 at 10:34

11 Answers 11


No, zipping a file cannot break it. Providing your zip file is not corrupted, it will reproduce the identical file when unzipped.

In this case, difference between fonts installed on the two different systems may cause issues but that is completely unrelated to the zip/unzip process.

  • 5
    That is what I suspected. Thanks for your answer.
    – alex
    May 13 '11 at 2:41
  • 35
    In addition, some zip formats support redundancy, meaning storing as a zip can actually be safer than storing the plain file. May 13 '11 at 4:25
  • You should not say no this quickly, there are a lot of zipping/unzipping file implementations out there, counting all existing OSes and other stuff which can make zip files, I would not be surprised that some implementations just don't care of some others.
    – jokoon
    May 14 '11 at 17:23
  • @jokoon: then those files would be corrupted, which he excludes explicitly
    – mbx
    May 14 '11 at 20:51
  • 3
    -1 In theory this is true, but in practice there are issues with Mac fonts being unzipped on a PC as 0 bytes. This is due to a resource fork being created. Try it for yourself and see. May 15 '11 at 13:54

In general usage, zip is lossless (assuming a bug-freeimplementation), but there is one scenario that could apply to data-loss: NTFS Alternate Data Streams. This little-used feature allows a single file to have multiple independent sets of contents. Most code will only ever see the unnamed stream, but others can exist.

So; if a program decided to store the data in an NTFS Alternate Data Stream, your zip client won't see that portion (it needs to explicitly ask for it, and RAR is the only one that does this currently).

But to emphasise: this is used very rarely, and not normally with things like PSD. I suspect your friend/associate is simply wrong.

  • 11
    Wow, this is totally new knowledge to me.
    – kizzx2
    May 13 '11 at 9:30
  • 5
    New to me and bizarre. When is a file not a file? When its contents mutate at will. I've heard of worse misfeatures, but not many.
    – msw
    May 13 '11 at 10:56
  • 7
    @msw - they don't mutate at will; simply - there can be more than one hunk of data associated with a single file record. Almost always there is exactly one (it is very rarely used), but...
    – Marc Gravell
    May 13 '11 at 11:03
  • 4
    Go back to SO! Too technical! (just kidding of course ;) May 13 '11 at 18:32
  • 3
    And on the other end of the spectrum, we have people complaining about system-specific metadata being forcibly included in archives.
    – Daniel Beck
    May 13 '11 at 19:03

There are circumstances in which a Mac font may not be identical if it is zipped and then unzipped. This may not break it, but contrary to some statements above, the process may not provide an identical file.

The circumstances are discussed here:



But in short:

  1. If they are much older fonts that contain resource forks and the user has an older version of Mac OS X, typically 10.4 or earlier. Legacy fonts like this work on OS X though they were originally intended for OS 9 and earlier versions of the Macintosh operating system. It is entirely likely (and, in my experience, common) that some folks are still using a font library they built as long as 20 years ago. Typically these are artists and art director types. For example, I have a few fonts with creation dates of 1993 and hundreds with creation dates of 1998, most with resource forks. Certainly I should have converted these to more modern formats or stopped using them, but let's face it: once you buy the Adobe Font Library, you never want to buy it again. In my years working with art directors in advertising, I learned to respect the font folder as if it were an art director's diary, commonplace book, or superego.

  2. Some metadata will be stripped in certain versions of the operating system. Metadata may be things added to the information field of the file. This will not break the file, but again, nor will the roundtrip zip-unzip produce an identical file.

PS: I am assuming here that if one is zipping a PSD file for delivery to another person, that it has not been flattened and that the font has not been converted to outline, which means that one would also deliver the font files with the PSD so that the person on the receiving end could make their own changes to the file. This is a common practice.

  • 2
    +1 - I wish I could give this enough points to push it to the top of the stack. Mac OS have both Type 1 and TrueType font variants where the font data is stored in the resource fork. While the native zip/unzip tools in the OS can handle this situation gracefully, not all tools (particularly command lines tools ported to OS X) will. What's worse, not zipping the fonts and trying to send them via email or FTP will break them!
    – afrazier
    May 13 '11 at 14:46
  • 1
    But the problem here appear to be with how you compress them, not whether you can. Seems like to need a program that understands resource forks and you have to know how to use it. Am I reading that right?
    – uSlackr
    May 13 '11 at 20:51
  • @uSlackr, right, but the problem persists at the receiving end. If the archive is then moved Windows, you will likely get a stack of useless font files because although Windows (specifically NTFS) does allow for multiple data streams in a file, fonts on Windows don't work that way. The PSD file itself is likely to be portable betwenn Mac and Windows, however.
    – RBerteig
    May 14 '11 at 0:45
  • +1 - as an example, save your Mac fonts on a network drive and then see how big they are from a Windows or Linux PC - 0 bytes! It is the resource fork thingy confusing the 'it just works' idea. May 15 '11 at 11:48
  • Yes, it's a well known fact in my industry that Mac fonts don't zip well. Often a PC user will unzip them 0 bytes. May 15 '11 at 13:53

ZIP uses checksum to check if the unpacked file is exactly the same as it was before packing.

So if it was changed in some reason (broken archive, for example) - it would not even be unpacked.

  • irrelevant since zip is using lossless compression (or 'storage', compression could be disabled). checksumming is only to beeing able to provide some feedback if something went wrong.
    – akira
    May 13 '11 at 5:07
  • 13
    Forgive the pedantry, but ZIP doesn't use a checksum - it uses a 32 bit cyclic redundancy check (aka CRC-32) which detects a much wider range of errors.
    – Bevan
    May 13 '11 at 9:08
  • 5
    The term "checksum" has clearly become somewhat broader in meaning than its original definition if people can [and they do] call the results of cryptographic hash functions "checksums".
    – Random832
    May 13 '11 at 14:36

Only if they're doing something silly like doing text-mode conversion on it, or if there's a broken zip/unzip somewhere that gets confused by an embedded zip. (Such bugs have occurred in the past — meaning maybe 10 years ago.)


Zip uses a loss-less compression algorithm to ensure that data you get back is identical to the data you put in.

(BTW, Other technologies like jpg, mpeg, mp3, use lossy techniques to compress with the theory that our eyes and ears are not so sensitive )


The only truth I could see in the statement "zipping breaks fonts" is if the PSD file format itself has a "compressed" version or option you can enable in whatever program creates these files and this option somehow handles fonts differently.

Using any zip program should be fine except if it's buggy.

In response to Marc, there are also potential filesystem issues on EXT filesystems if you try and zip a directory structure containing soft and hard links in a zipped format that doesn't understand these (which is why I always make a .tar.gz instead of a .zip there). Also, zipping soft links with relative paths then unzipping them somewhere else won't of course work, but that's not the zip program's fault.


If they have had that issue before (zipping corrupting a PSD) then either their compressor software is faulty, they are not including all the files they need on the PSD, and/or their computers are infected with a virus.

I would ask them if they have had similar corruptions by moving files to usb disks, just to discard that last option.


Just to add one more caveat for completeness: Zipping may cause the file's meta-data, such as permissions or last-accessed-time to be lost.

I do not believe that is generally relevant to PSD files and fonts.

  • I think there is a misunderstanding to the concept of a lossless compression algorithm and programs that perform this task. Lossless means, the binary stream that is compressed will be decompressed to the identical output binary stream. Meta informations are OS dependent and have to be handled by the OS and/or the application.
    – Bora
    May 14 '11 at 21:08
  • 1
    Thanks, @Bora, but I have no such misunderstanding. I realise zipping doesn't affect the actual data in the file. I am suggesting an "external" cause that may fool people into thinking the zip damaged their files and directories. I have been caught in the past by restoring zipped up backups, only to find that my applications no longer worked, because they depend on meta-data I didn't bring across. (Not a basic misunderstanding on my part, but merely an oversight.) May 15 '11 at 2:31

Zip can corrupt filenames. Zip as such does not use unicode. The encoding of filenames is unspecified and on windows current locale is used.

Therefore when transferred to a different system your filenames will be messed up.

There is an extension to Zip format that most recent programs (winzip since version 11 I think) use.

I prefer 7z eversince I had a zip full of japanese names unable to unzip it.


A zip file is supposed to be able to reproduce the contents exactly.

One related note though -- it is more difficult to recover the data if a zip file gets corrupt, than if the data was in the original format. Why? Many file formats have built in redundancy, and are designed so that either minor errors are correctable, or minor errors are not critical.

Imagine a video file. In most formats, if a small portion gets corrupt, you will see a temporary flicker in that small portion of the video but can still watch the video. But if the video file is zipped, the error correction capability is reduced, and depending on the extent of corruption, you simply may not be able to unzip the file / watch the video. (This is contrived example as it is useless to zip most video formats in any case).

This is true for any compression format - compression by definition reduces reduncancy and hence error correction capabilities and its a trade-off.

  • As a comment above said, some zip file formats support redundancy. This can make it even safer than the original format.
    – DMan
    May 14 '11 at 16:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.