file

What it does

file examines a file's actual content — its magic bytes and internal structure — rather than trusting its name or extension, and reports what kind of file it really is: text, a specific image format, an executable, an archive, a script, and so on. This makes it invaluable for identifying files with missing, wrong, or suspicious extensions.

Beginner examples

• file document.pdf — confirm a file really is a PDF
• file * — identify every file in the current directory
• file unknown_download — figure out what a file with no useful extension actually is
• file script.sh — check whether a script is a shell script, and which interpreter it expects

file ~/Downloads/mystery_file

Advanced examples

• Get a machine-readable MIME type for use in scripts: file -i uploaded_file
• Peek inside a compressed archive without extracting it: file -z backup.tar.gz
• Check the type of what a symlink actually points to: file -L /usr/bin/python
• Identify every file's type in bulk and pipe to further processing: file * | grep "ASCII text"
• Inspect a device file's type (needs appropriate permissions): file -s /dev/sda1

find . -type f -exec file {} \; | grep -i "executable"

Common mistakes

• Trusting a file's extension over what file reports — a .txt file can actually be a renamed image, script, or executable, and file will reveal that mismatch.
• Assuming file can always determine a definitive type — some ambiguous or corrupted files get reported simply as "data" when no known signature matches.
• Forgetting -z when trying to identify content inside a compressed file, and only getting "gzip compressed data" instead of what's inside it.
• Using file on a huge directory of files without redirecting output, producing an overwhelming wall of text; pipe through grep or less instead.

Tips

• Use file -i when you need output suitable for scripting or comparison, since MIME types are more standardized than the free-form human descriptions.
• Combine file with find to audit a directory for unexpected file types, e.g. finding executables hiding among what should be plain documents.
• Before opening or executing an unfamiliar downloaded file, run file on it first as a quick sanity check.

Best practices

• Always verify unknown or user-uploaded files with file (or equivalent magic-byte inspection) before processing them — never trust a client-supplied extension or Content-Type header alone for security-sensitive handling.
• In upload-handling scripts, combine file -i output with an allowlist of expected MIME types rather than filtering purely on file extension.
• Use file as a first diagnostic step when a tool refuses to open a file, since it often reveals the file is not the type you assumed.

Real-world use cases

• Verifying an uploaded file's real type server-side before accepting it, to guard against disguised executables or scripts.
• Figuring out what a mystery file left behind by a coworker or a backup actually is, when it has no extension.
• Confirming a downloaded installer or archive isn't corrupted or mislabeled before running it.

Common interview questions

• How does the file command determine a file's type? It reads the file's contents and matches known byte-sequence signatures ("magic numbers") against a magic database, rather than relying on the filename or extension.
• Why shouldn't you trust a file's extension for security purposes? Extensions are just naming conventions that can be wrong or deliberately spoofed; the file command's content-based detection is far more reliable for determining what a file actually is.
• How would you check what type of content is inside a .gz archive without extracting it? file -z archive.gz, which inspects the compressed content and reports both the compression format and the type of data inside.