Take the 2-minute tour ×

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?

share|improve this question
Maybe the other person has confused zipping a file (lossless) with jpeg compression (lossy) which can make test look ugly. –  Matt H 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
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. –  FumbleFingers May 13 '11 at 13:51
@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. –  FumbleFingers 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

up vote 125 down vote accepted

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.

share|improve this answer
That is what I suspected. Thanks for your answer. –  alex May 13 '11 at 2:41
In addition, some zip formats support redundancy, meaning storing as a zip can actually be safer than storing the plain file. –  BlueRaja 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
-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. –  Django Reinhardt 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.

share|improve this answer
Wow, this is totally new knowledge to me. –  kizzx2 May 13 '11 at 9:30
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
@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
Go back to SO! Too technical! (just kidding of course ;) –  Byron Whitlock May 13 '11 at 18:32
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.

share|improve this answer
+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
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. –  Django Reinhardt 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.

share|improve this answer
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
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
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.)

share|improve this answer

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 )

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
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
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.) –  Oddthinking 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.

share|improve this answer

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.

share|improve this answer
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

protected by studiohack May 15 '11 at 13:06


Would you like to answer one of these unanswered questions instead?
