File command in Linux

A file’s name on Linux doesn’t always tell you what’s inside, since a file ending in .dat can hold plain text. The file command looks at the contents and tells you what kind of data the file holds.

I’ll show you how to check one file or many at once, and how to get output that scripts can use.

What the file command identifies

The file command identifies a path by checking its filesystem properties and, for ordinary data, matching its contents against known formats. Its result describes the kind of data it recognized, not whether the file is safe, authentic, or correctly named.

The tests run in order: filesystem checks, magic-signature checks, then text and language checks. The magic database stores rules for byte signatures at known offsets. The final text checks can report encoding and clues such as line endings, so file can identify a script even when its suffix does not say what it contains.

The filename extension is not the deciding evidence. A file named notes.dat can contain plain text, while a familiar suffix can disagree with the bytes inside it. The file(1) manual documents the test order and the options used below.

What you need to inspect a path

You need a shell with the file utility installed and permission to access the path. The examples below use local sample files and file version 5.45. Descriptions can vary with the installed magic database and platform.

A directory is a valid argument, but file does not recursively inspect its contents. A shell wildcard is expanded before file receives the resulting paths.

Check the installed utility version before relying on an option or exact wording. Special devices may need separate handling.

file --version

Step 1: Identify one path and read the result

Run file followed by a path to print the path and its detected type. The output here distinguishes plain text, JSON data, and a directory without relying on suffixes.

file demo/notes.dat demo/settings.json demo && file -i demo/settings.json

The first command reports ASCII text, JSON text data, and directory. The second reports application/json with a character-set parameter, which is useful when another program needs a Multipurpose Internet Mail Extensions (MIME) media type instead of a descriptive label. I ran these checks on the sample paths shown here.

For the MIME type alone, use file –mime-type demo/settings.json. Add –mime-encoding when you need only the encoding, or use -b to omit the path from ordinary output.

Step 2: Choose output for scripts and lists

These options change how file presents the classification, not the underlying question it asks. Pick the form that the next command or person can consume.

For automation, prefer a defined output field such as –mime-type over parsing descriptive text. The command still returns its own classification, so check the exit status and handle unreadable or missing paths separately.

Step 3: Inspect several paths or a list

In a directory, the shell expands a wildcard such as demo/* before file receives the matching paths. For a prepared list, use -f with one path per line. The list file supplies names to inspect, not shell commands.

1. Inspect known paths with file demo/notes.dat demo/settings.json.
2. Inspect entries matched by the shell with file demo/*.
3. Read a prepared path list with file -f demo/file-list.txt.

Step 4: Follow links and inspect compressed content

By default, file reports a symbolic link itself on systems where link handling is supported. Use -L to classify the target instead. The -h option requests that links not be followed.

file demo/notes-link
file -L demo/notes-link
file -z demo/notes.txt.gz

The first two commands separate the link from its target, which lets you see whether you are classifying the link or the file it points to. The -z option asks file to inspect compressed contents when supported.

Here, file -z reports the inner text classification alongside gzip metadata, though a malformed or unreadable stream can limit what it identifies.

For a custom magic file, -m selects the rules file, while -c prints a checking view of the parsed rules. The latter is for debugging magic definitions, not a general option for showing how an ordinary file was parsed.

When a file result is not proof of authenticity

file identifies recognizable structure, but it does not validate a download’s publisher or guarantee that every byte is valid for the format. A renamed file can still be detected from its content. A matching label alone does not establish that it is safe to open.

Results may differ across systems because magic databases and utility versions differ. A path that is missing or unreadable can produce an error or a classification based on limited metadata, so confirm the path and permissions before treating an unexpected result as a format issue.

• Check the path spelling and whether it is a symlink.
• Use –mime-type when you need a stable media-type field.
• Use a checksum or signature verification procedure when provenance matters.

Keep classification separate from verification

Use file to learn what a path appears to contain, then choose the next tool for the task: inspect a text file with a viewer, unpack an archive with the appropriate utility, or verify a download with its published checksum or signature. The detected format helps you choose that tool, but does not certify who produced the file.

file --mime-type demo/settings.json

For the next step, see the Linux guides to gzip compression, tar archives, symbolic links, listing paths with ls, and counting lines in a text file.

File command questions

The questions below cover filename suffixes, MIME output, compressed paths, and directories. Their answers distinguish a path’s name from the content that file reports.