The chmod calculator above converts in both directions between the octal permission numbers Unix systems use and the rwx notation that ls -l prints. Type a number and the checkboxes follow; tick the boxes and the number follows. It also assembles the exact command to run, including the special-bit digit when setuid, setgid or the sticky bit is involved, and flags the combinations that are usually mistakes.
Arb Digital publishes this alongside its other free developer utilities because permission numbers are one of those things people either know cold or look up every single time, with very few in between. The conversion is simple arithmetic, but getting it wrong on a production server means either a broken deployment or a security hole, and the difference between those two outcomes is often one digit.
What This Chmod Calculator Does
Unix file permissions are stored as a small bitfield. Nine bits cover read, write and execute for three classes of user — the file's owner, the file's group, and everybody else — and three further bits hold setuid, setgid and the sticky flag. Because three bits fit exactly into one octal digit, the whole thing is conventionally written as a three- or four-digit number in base eight. That is the entire reason octal survives in modern computing when almost nothing else uses it.
The calculator makes that mapping explicit. Each grid cell shows one class's digit, so you can see that 6 means read plus write and 5 means read plus execute without having to add the values in your head. The note underneath shows the full mode line as it would appear in a directory listing, the symbolic form you would pass to chmod if you preferred letters to numbers, and the command itself with your target path filled in.
Boundary worth stating: this is a permissions tool, not a general base converter. If you are converting arbitrary numbers between binary, octal, decimal and hexadecimal, the number base converter is the right page. This one is specific to the permission bitfield and its conventions.
How to Use It
- Type an octal number if you already have one from documentation or a tutorial, and read off what it actually grants. Three digits are assumed to have a leading zero for the special bits.
- Or tick the boxes to build a mode from intent rather than from memory, and watch the number assemble itself.
- Pick a preset to see the modes that come up most often in real work, including the three special-bit cases that are easy to get wrong.
- Set the target path and type. The type changes the leading character of the mode line from a dash to a d, and adjusts what the tool warns you about.
- Copy the command from the note. It is written in the same form you would paste into a shell.
The Formula and How It's Calculated
Each permission has a value: read = 4, write = 2, execute = 1. Add the values a class should have and you get its digit. Read plus write is 4 + 2 = 6. Read plus execute is 4 + 1 = 5. All three is 7. None is 0. Because 4, 2 and 1 are distinct powers of two, every digit from 0 to 7 decodes to exactly one combination, which is what makes the notation unambiguous.
Concatenate the owner, group and other digits in that order and you have the familiar three-digit mode. 644 is owner read-write, group read, others read. 755 is owner read-write-execute, group and others read-execute. The optional leading digit uses the same scheme for the special bits: setuid = 4, setgid = 2, sticky = 1, so 4755 is a setuid executable and 1777 is a world-writable directory with the sticky bit set.
The symbolic form expresses the same information as letters against user classes: u for owner, g for group, o for others and a for all, combined with +, - or =. The authoritative definition of both notations is in the POSIX specification for chmod, which states that the mode operand is either a symbolic mode expression or a non-negative octal integer, and gives the full grammar for the symbolic form.
Why the Execute Bit Means Something Different on a Directory
This is the single most useful thing to understand about Unix permissions, and it is rarely explained clearly. On a regular file, the execute bit means what you would expect: the file may be run as a program or script. On a directory, it means something entirely unrelated — it grants permission to traverse the directory, which is to say to access things inside it by name.
The consequences are not intuitive. A directory with read but not execute lets you list the names of its contents but not open any of them or read their metadata, so ls works and ls -l mostly does not. A directory with execute but not read lets you open a file inside it if you already know its exact name, but not discover what is there — which is a genuinely useful configuration for a directory holding secrets whose names are known only to the application. This is also why 644 on a directory breaks everything while 644 on a file is perfectly ordinary, and why web servers returning "403 Forbidden" on a path that clearly exists are usually missing an execute bit on a parent directory rather than on the file itself.
Why 777 Is Almost Never the Right Answer
When something does not work, 777 makes it work, and that is exactly the problem: it removes the permission system rather than fixing the permission. A mode of 777 lets every account on the machine read, modify and execute the file. On a shared host that includes other customers. On a web server it means any process that manages to write a file — including one running through a vulnerable upload form — can also overwrite your application code and have the server execute it.
The narrower fix is almost always ownership rather than permission. If a web server needs to write to an uploads directory, the correct move is to make that directory owned by the web server's user or group and grant 775 or 755 accordingly, not to open it to the world. Some PHP and CGI configurations actively refuse to execute scripts that are group- or world-writable, so 777 can break the very thing it was meant to fix. If your reason for reaching for 777 is a deployment problem, the htaccess redirect generator and a look at your server configuration will usually get further than widening the mode.
The Three Special Bits and What They Actually Do
setuid (4000) on an executable makes it run with the privileges of the file's owner rather than the user who launched it. It is how passwd can edit a root-owned file when an ordinary user runs it, and it is a serious security consideration: a setuid-root binary with a bug is a privilege-escalation route. It has no effect on directories on Linux and is ignored on scripts by most modern kernels.
setgid (2000) does the equivalent for the group on an executable, but on a directory it does something far more commonly useful: new files created inside inherit the directory's group rather than the creating user's primary group. That is the standard way to set up a shared project directory where several accounts need to collaborate without fixing group ownership by hand every time.
The sticky bit (1000) on a directory restricts deletion: a user may only remove or rename files they own, even when the directory itself is writable by everyone. This is why /tmp is mode 1777 — anyone can create files there, but nobody can delete anyone else's. The chmod(1) manual page in the Linux man-pages project documents this as the restricted deletion flag and covers the behaviour of all three bits in detail.
Why New Files Never Have the Mode You Expect
Create a file and check it, and the mode will usually be 644 rather than the 666 that many programs request. The reason is the umask, a per-process mask that subtracts permission bits from whatever a program asks for at creation time. A typical umask of 022 clears the write bit for group and others, turning a requested 666 into 644 and a requested 777 into 755. A umask of 002, common on systems with per-user groups, leaves group write in place and yields 664 and 775.
Two practical points follow. First, the umask only applies at creation; it never modifies an existing file, so it explains what you get from a fresh touch but not what happens after an explicit chmod. Second, files copied or extracted from archives may carry modes from wherever they came from, which is why deployments so often need an explicit permission pass rather than trusting whatever landed on disk. When you are scripting that pass, a scheduled run built with the cron expression generator is a common way to keep it enforced.
Arb Digital designs and builds fast, secure websites — sensible permissions, clean deployments, and no 777 directories anywhere near production.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Using 777 to make something work. It disables the protection rather than fixing the cause, and some server configurations refuse to execute world-writable scripts anyway.
- Applying the same mode recursively to files and directories. Directories need the execute bit to be traversable; a blanket recursive 644 makes an entire tree inaccessible.
- Confusing permissions with ownership. If the wrong account owns a file, no mode fixes it. That is a job for chown, not chmod.
- Forgetting the leading digit. Running chmod with 755 on a file that had the setuid bit set silently clears that bit, because a three-digit mode zeroes the special digit.
- Expecting the umask to change existing files. It only filters permissions at creation time and has no effect on anything already on disk.
Related Free Tools From Arb Digital
For converting arbitrary values rather than permission bits, use the number base converter. Server-side work often pairs with the htaccess redirect generator for Apache rewrite and redirect rules. The cron expression generator builds schedule strings for the maintenance jobs that enforce permissions, the hash generator produces checksums for verifying deployed files, and the UUID generator covers identifier needs. Everything else is in the free online tools hub.
Frequently Asked Questions
The owner gets read, write and execute; the group and everybody else get read and execute but not write. It is the standard mode for a directory or an executable script that should be usable by others but modifiable only by its owner.
The execute bit. 644 grants owner read-write and everyone else read-only, which suits ordinary data files. 755 adds execute for all three classes, which a script needs to run and a directory needs to be entered at all.
Read is worth 4, write 2 and execute 1, and you add the values for each class of user. Read plus write gives 6, read plus execute gives 5, and all three gives 7. The digits appear in the order owner, group, others.
No. It lets every account on the system read, modify and execute the file, which on a shared server includes other customers and any compromised process. The usual correct fix is to adjust ownership so a narrower mode such as 775 or 755 works instead.
It holds the special bits, using setuid 4, setgid 2 and sticky 1. So 4755 is a setuid executable, 2775 is a setgid shared directory, and 1777 is a world-writable directory with the sticky bit that stops users deleting each other's files.
Because on a directory it means permission to traverse rather than to run. Without it you cannot open files inside by name even if you can list them, which is why a directory set to 644 appears broken while the same mode on a file is completely normal.
The umask subtracts bits at creation time. A typical umask of 022 clears group and other write, turning a requested 666 into 644 and a requested 777 into 755. It applies only when files are created and never alters existing ones.
Yes. Symbolic mode uses u, g, o and a for the user classes with the operators plus, minus and equals, so u+x adds execute for the owner and go-w removes write for group and others. The calculator shows the symbolic equivalent of whatever mode you build.
