That it compresses the data compared to the pixel array is obvious.But what makes it different from from normal compression (like png, jpeg)? 
How does hardware texture compression work?
texture;compression
As Simon's comment alluded to, one major difference between hardware texture compression and other commonly used image compression is that the former does not use entropy coding. Entropy coding is the use of shorter bit-strings to represent commonly-occurring or repeating patterns in the source data—as seen in container formats like ZIP, many common image formats such as GIF, JPEG, and PNG, and also in many common audio and video formats.Entropy coding is good at compressing all sorts of data, but it intrinsically produces a variable compression ratio. Some areas of the image may have little detail (or the detail is predicted well by the coding model you're using) and require very few bits, but other areas may have complex detail that requires more bits to encode. This makes it difficult to implement random access, as there is no straightforward way to calculate where in the compressed data you can find the pixel at given (x, y) coordinates. Also, most entropy coding schemes are stateful, so it's not possible to simply start decoding at an arbitrary place in the stream; you have to start from the beginning to build up the correct state. However, random access is necessary for texture sampling, since a shader may sample from any location in a texture at any time.So, rather than entropy coding, hardware compression uses fixed-ratio, block-based schemes.  For example, in DXT / BCn compression, the texture is sliced up into 4×4 pixel blocks, each of which is encoded in either 64 or 128 bits (depending on which format is picked); in ASTC, different formats use block sizes from 4×4 up to 12×12, and all blocks are encoded in 128 bits. The details of how the bits represent the image data vary between formats (and may even vary from one block to the next within the same image), but because the ratio is fixed, it's easy for hardware to calculate where in memory to find the block containing a given (x, y) pixel, and each block is self-contained, so it can be decoded independently of any other blocks.Another consideration in hardware texture compression is that the decoding should be efficiently implementable in hardware. This means that heavy math operations and complex dataflow are strongly disfavored. The BCn formats, for instance, can be decoded by doing a handful of 8-bit integer math operations per block to populate a small lookup table, then just looking up the appropriate table entry per pixel.  This requires very little area on-chip, which is important because you probably want to decode several blocks in parallel, and thus need several copies of the decode hardware.In contrast, DCT-based formats like JPEG require a nontrivial amount of math per pixel, not to mention a complex dataflow that swaps and broadcasts various intermediate values across pixels within a block. (Look at this article for some of the gory details of DCT decoding.) This would be a lot grosser for hardware implementation, which I'm guessing is why AFAICT, no GPU hardware has ever implemented DCT-based or wavelet-based texture compression.