Editing Lempel–Ziv–Welch (section)

===Variable-width codes===
If variable-width codes are being used, the encoder and decoder must be careful to change the width at the same points in the encoded data so they don't disagree on boundaries between individual codes in the stream. In the standard version, the encoder increases the width from ''p'' to ''p''&nbsp;+&nbsp;1 when a sequence ω&nbsp;+&nbsp;''s'' is encountered that is not in the table (so that a code must be added for it) but the next available code in the table is 2<sup>''p''</sup> (the first code requiring ''p''&nbsp;+&nbsp;1 bits).  The encoder emits the code for ω at width ''p'' (since that code does not require ''p''&nbsp;+&nbsp;1 bits), and then increases the code width so that the next code emitted is ''p''&nbsp;+&nbsp;1 bits wide.

The decoder is always one code behind the encoder in building the table, so when it sees the code for ω, it generates an entry for code 2<sup>''p''</sup>&nbsp;&minus;&nbsp;1.  Since this is the point where the encoder increases the code width, the decoder must increase the width here as well—at the point where it generates the largest code that fits in ''p'' bits.

Unfortunately, some early implementations of the encoding algorithm increase the code width and ''then'' emit ω at the new width instead of the old width, so that to the decoder it looks like the width changes one code too early.  This is called "early change"; it caused so much confusion that Adobe now allows both versions in PDF files, but includes an explicit flag in the header of each LZW-compressed stream to indicate whether early change is being used.  Of the graphics file formats that support LZW compression, [[TIFF]] uses early change, while [[GIF]] and most others don't.

When the table is cleared in response to a clear code, both encoder and decoder change the code width after the clear code back to the initial code width, starting with the code immediately following the clear code.