“Magic number” is one term with two distinct meanings in programming, both about a literal value whose significance is not self-evident. In the first sense it is a code smell: an unexplained numeric constant dropped directly into source code, such as a loop that runs to 86400 or a check against 0.7. In the second sense it is a useful, deliberate convention: a fixed sequence of bytes at the start of a file that identifies its format. The shared name reflects a shared quality, a number that carries meaning only to those who already know the secret.
As a code smell, the magic number is criticized because the bare literal hides intent. A reader cannot tell whether 86400 is a count of seconds in a day, an arbitrary buffer size, or a coincidence, and if the same value appears in several places, changing it safely becomes guesswork. The standard remedy is to replace the literal with a named constant, such as SECONDS_PER_DAY, so the name explains the value and a single definition governs every use. Style guides reinforce this through the broader push for readable, self-explaining code; Python’s PEP 8, for instance, frames its conventions around code that communicates intent rather than forcing the reader to decode unexplained details.
The second sense is older and entirely benign. Many file formats begin with a signature, a magic number, that lets a program recognize the type without trusting the file name. The Unix file command is built on exactly this idea. Its manual page explains that magic tests look for an invariant identifier at a small fixed offset into the file, and notes that any file with such an identifier near its start can usually be described this way. The concept came from executables: a compiled program carries a magic number near its beginning that tells the operating system it is runnable and what kind of binary it is.
The file command reads its knowledge of these signatures from a magic database. The magic(4)/magic(5) manual page documents the format of that database, describing how each entry specifies a file offset, a value to compare against, the message or MIME type to print on a match, and additional data to extract. This is how a single tool can identify hundreds of formats: a PDF begins with the bytes that spell %PDF, an ELF executable begins with 0x7F followed by ELF, and a Java class file begins with the famous 0xCAFEBABE chosen by its designers as a memorable signature.
The two meanings sometimes collide in the same breath, since a file’s magic number is itself a hard-coded constant inside a program that parses it. The difference is intent and documentation. A format signature is a published, agreed-upon contract; an unexplained literal in business logic is an accident waiting to confuse the next maintainer. One is magic by design, the other magic by neglect.
Both senses teach the same underlying lesson about names. Programs are easier to trust when the meaningful numbers in them are labeled, whether that label is a constant in source code or a registered signature in a format specification. The cure for a bad magic number and the strength of a good one are the same thing: knowledge that has been written down rather than left to be guessed.