Chmod Calculator
Convert Unix file permissions between octal (755), symbolic (rwxr-xr-x), and checkbox grid.
| Read (r) | Write (w) | Execute (x) | |
|---|---|---|---|
| Owner (u) | |||
| Group (g) | |||
| Others (o) |
chmod 755 file
find . -type f -perm 755
Note: macOS and Linux may behave differently for setgid on directories — test on your target OS.
How to use
- Enter an octal (e.g.
755,644,4755) or click a preset chip. - Use the rwx checkbox grid to toggle individual bits. The octal and symbolic forms update together.
- Copy the chmod or find command from the output panel.
About this tool
ShowHide
A two-way calculator for Unix file permissions. Type an octal like 755 or 4755, or click the grid of read, write and execute boxes for owner, group and others, and the symbolic form updates live. The panel gives you a chmod command, a matching find -perm expression and the equivalent umask, so whichever one your shell session wants is there to copy.
The special bits are where the symbolic notation gets subtle, and the tool renders them the way ls does. Setuid (4000), setgid (2000) and the sticky bit (1000) each replace the execute character in their own column: lowercase s or t when execute is also set, uppercase S or T when it is not. That capital letter is almost always a mistake worth catching — 4644 shows rwSr--r--, a file marked setuid that nothing can execute, which does nothing except look alarming in an audit.
What each special bit actually does is worth keeping straight, because only one of the three means the same thing everywhere. Setuid on an executable runs it as its owner, and Linux deliberately ignores it on shell scripts, so a setuid .sh is not the security hole it looks like — it simply has no effect. Setgid on a directory is the genuinely useful one: new files inside inherit the directory's group rather than the creator's, which is how a shared project directory stays shared. The sticky bit on a directory, as on /tmp, means only a file's owner, the directory's owner or root can delete it, regardless of the directory's write permission.
The umask shown is the complement of the mode against 777, which is the number you type but not always the mode you get. Umask subtracts, and the starting point differs by kind: directories start from 777 and files from 666, because files are not given the execute bit by default. So a umask of 022 produces 755 directories and 644 files from the same setting. And the standing warning: chmod 777 is almost never the fix. It is the permission of last resort, it makes the files it is applied to readable, writable and executable by every user and process, and the problem it appears to solve is usually ownership or a missing execute bit on a parent directory.
Frequently asked questions
What's the difference between s and S in symbolic mode?
Lowercase s means setuid/setgid is set AND the execute bit is set. Uppercase S means the special bit is set but execute is NOT — usually a configuration mistake worth investigating.
What does the sticky bit do?
On directories, the sticky bit (1xxx, shown as t) restricts file deletion: only the file's owner, the directory's owner or root can delete files in that directory, even if others have write permission. Classic example: /tmp is 1777.
How is umask computed?
umask is the inverse of the permissions you want new files to have. If you want files to default to 644, umask is 022 (new files start from 666 and directories from 777, and the umask bits are removed: 666 − 022 = 644, 777 − 022 = 755).
Why can I still not enter a directory that shows read permission?
Because on a directory the bits mean something different from a file: read lists the names inside, write creates and removes entries, and execute is what permits traversing into it or reaching anything below. A directory with read but not execute lets you see the names and open nothing, and one with execute but not read lets you open a file whose name you already know while ls fails.
Why does permission on the file not seem to control deletion?
Because deleting is an operation on the directory, not on the file: it removes an entry, so write permission on the containing directory is what decides it. That is why a read-only file in a writable directory can still be removed, and it is the reason the sticky bit exists — on a shared directory it restricts each entry's removal to its owner, the directory's owner and root.
Related tools
Hex Dump Viewer
Inspect text or a small file as offset + hex bytes + printable ASCII, like xxd or hexdump -C.
Developer
MIME Type Lookup
Find the MIME type for a file extension (or the other way around) and learn what each type is for.
Developer
systemd Service File Generator
Build a .service unit file for systemd — Type, Restart, User, Environment, sandboxing — plus the install and journalctl commands.
Developer
BSON Decoder & Extended JSON Viewer
Decode a MongoDB BSON file in your browser: every element type with its type byte, exact int64 and decimal128, and canonical or relaxed Extended JSON.
Developer
Java .properties Parser
Parse a .properties file exactly as java.util.Properties.load does — separators, escapes, continuations — and see every line that will surprise you.
Developer
Python Pickle Inspector
Disassemble a .pkl file in the browser: every opcode, the memo, the value it rebuilds, and whether loading it would run code.
Developer