Chmod Calculator

Numeric / Symbolic

How to use this chmod calculator

  1. Check the read/write/execute boxes for Owner, Group, and Others.
  2. The numeric code (like 755) and the ready-to-use command update instantly.
  3. Copy the command and run it in your terminal.

How do Unix file permissions work?

Every file has three permission sets — for the owner, the group, and everyone else — each with read (4), write (2), and execute (1) bits. Adding those numbers gives the digit for that group, so 755 means the owner can read/write/execute, while group and others can only read/execute.

What does 777 mean, and why is it usually a bad idea?

777 gives everyone full read, write and execute access. It's convenient for testing but a serious security risk on real servers, since it lets any user modify or run the file.

What's a typical safe permission for a website file?

644 for regular files (owner can read/write, everyone else read-only) and 755 for directories and scripts that need to be executed are common, secure defaults.

Why the execute bit means something completely different for a directory

The execute permission bit works intuitively for regular files — it controls whether the file can be run as a program or script. For a directory, though, execute means something else entirely: it controls whether you can actually enter that directory and access the files inside it (technically, whether you can traverse it), not whether the directory itself can be "run." This is exactly why a directory commonly needs execute permission even though nobody would ever try to run a folder as a program, and it's precisely why a common permission-troubleshooting mistake is granting read permission on a directory without also granting execute — read alone lets you list what filenames exist inside, but without execute you can't actually access or open any of those files, producing a confusing "permission denied" even though the directory listing itself worked fine.

The hidden fourth digit — setuid, setgid, and the sticky bit

Beyond the familiar three-digit permission code (owner/group/others), Unix permissions actually support an optional fourth leading digit representing three special, less commonly used bits. Setuid, when set on an executable file, makes it run with the file owner's permissions rather than the permissions of whoever actually launched it — the classic historical example being the "passwd" command, which needs elevated privileges to modify the system's password file regardless of which regular user runs it. Setgid works similarly but for group ownership, and on a directory specifically, it makes newly created files inside automatically inherit that directory's group instead of the creating user's own default group. The sticky bit, most commonly seen on world-writable shared directories like /tmp, restricts file deletion within that directory so only a file's own owner (or root) can delete or rename it, even though everyone technically has write access to the shared directory itself.

Symbolic notation and why chmod also accepts letters, not just numbers

Beyond the numeric notation this tool computes (755, 644, and similar), chmod also accepts a symbolic notation using letters, and it's worth knowing both because each is better suited to different situations. Symbolic notation combines a target (u for user/owner, g for group, o for others, a for all), an operator (+ to add a permission, - to remove one, = to set it exactly), and a permission letter (r, w, or x) — for example, chmod u+x script.sh adds execute permission for the owner only, without needing to know or recalculate the file's other existing permission bits at all. This makes symbolic notation genuinely more convenient for making one small, targeted adjustment to an existing file's permissions, while numeric notation remains more common for setting a file's complete permission state all at once, which is exactly the calculation this tool performs.

Why the principle of least privilege applies directly to file permissions

The security principle of least privilege — granting only the minimum access actually needed for something to function, nothing more — applies just as directly to file permissions as it does to user account access or API scopes. Every unnecessary write or execute permission granted to "group" or "others" is a small but real expansion of what could go wrong if that specific account, service, or process is ever compromised or misused. This is exactly why 644 (owner can read/write, everyone else read-only) is the standard, sensible default for most regular files rather than something more permissive, and why 777 (full read/write/execute for literally everyone) is considered a serious security anti-pattern on any real, production system rather than a harmless convenience shortcut — it removes the very access boundary that permissions exist to enforce in the first place.

Limitations of this tool

This tool calculates the standard three-digit chmod permission code and its corresponding command from your read/write/execute selections — it doesn't currently calculate the special fourth digit (setuid, setgid, sticky bit) described above, or generate symbolic notation commands, since those cover more advanced, less frequently needed use cases. It also can't verify your actual current permissions on a real file or apply the generated command for you — it's a calculator for constructing the correct command, which you'll still need to run yourself in your own terminal against the actual file or directory.