Packers, also known as compressors, are tools used to compress the host down to a smaller size. The concept of compressing data helps us to reduce the time taken to transfer any data. At the obfuscation side, compressed data will most likely not show complete readable text.

In the following figure, the left pane shows the code's binary and data before getting compressed, while the one on the right shows its compressed form. Notice that the text strings are not completely found in the compressed form:

Given that the code and data are now compressed, executing the file would require a code that decompresses it. This code is called the decompression code stub. 

In the following figure, the original structure of the file is shown at the left with the program entry point in the code section. A probable packed version would have a new structure (right) with the entry point starting in the decompression stub:

When the packed executable is executed, the stub runs first and, afterwards, passes the code execution to the decompressed code. The entry point in the header should point to the address of the stub.

Packers reduce the size of some of the sections and thus must change values in the file header. The raw location and size of the sections are modified. As a matter of fact, some packers would treat the file as one big section containing both the code and data within it. The trick is to set this one big section with readable, writable, and executable attributes. However, this may run the risk of having improper error handling, especially when code accidentally writes to a supposedly read-only area, or executes code to a supposedly non-executable area.

The end result of a packed file is to get the host behavior intact with a packed file having a smaller file size.