Chmod Calculator
Convert between numeric and symbolic UNIX permissions.
About this tool
Chmod Calculator translates between the three ways to express UNIX file permissions: octal (755, 644), symbolic (rwxr-xr-x, rw-r--r--), and symbolic mode (u=rwx,go=rx, the form chmod itself accepts as input). Click the read/write/execute checkboxes for owner/group/other and the three representations update in lockstep, with the equivalent chmod command shown ready to copy.
Special bits are supported too: setuid (4000), setgid (2000), and sticky (1000) — the bits that turn /tmp into a shared writable directory where users cannot delete each other's files (sticky), and that let binaries like passwd escalate privileges (setuid). The display annotates each with its security implication so you know what you are about to apply.
When to use this tool
- Hardening web-server file trees. Confirm
644for files and755for directories before changing anything inchmod -R. - Troubleshooting "permission denied". Decode the result of
ls -linto octal to compare against what your app expects. - Setting up shared directories. Get the sticky-bit combination right (
1777) for a multi-user upload folder. - Learning UNIX permissions. The interactive bit-checkboxes are the fastest way to understand how octal maps to rwx.
About umask and default permissions
Theumask is the inverse of the calculator output — it tells the kernel which bits to turn off when a new file or directory is created. A common umask 022 gives you 644 files and 755 dirs by default; a stricter umask 077 gives 600 files and 700 dirs (private to owner). Picking the right umask system-wide is more efficient than chmod-ing every file individually.
Frequently asked questions
What is the difference between 644 and 755?
644 is "owner reads/writes, everyone else only reads" — the right default for static files (HTML, CSS, images). 755 adds execute for everyone, which is meaningless for static files but essential for directories (without execute on a directory, you cannot cd into it) and for scripts/binaries. The rule of thumb: 644 for files, 755 for directories.
What does setuid actually do?
/usr/bin/passwd has setuid root so a regular user can change their password (which requires writing to /etc/shadow). It is a powerful but dangerous permission; only system binaries should have it, never user scripts. Shell scripts ignore setuid for security reasons in modern UNIX.
Why is execute needed on directories?
cd into the folder, list its contents (with ls read is also needed), or read any files inside even if those files have read permission. A directory with read-only mode (444) is broken — you can see the names but you cannot stat any of them.
What is the sticky bit good for?
/tmp uses 1777 — everyone can write, but you can only remove your own files. Without sticky, anyone could rm anyone's tempfiles. The bit comes from a legacy use on executables (kept text in swap), now obsolete on files; on directories it is still very useful.