Skip to content
AZ Tools

Chmod Calculator

Convert Unix file permissions between octal (755), symbolic (rwxr-xr-x), and checkbox grid.

Common presets
Read (r)Write (w)Execute (x)
Owner (u)
Group (g)
Others (o)
Special bits
chmod command
chmod 755 file
find command
find . -type f -perm 755
Equivalent umask: 022

Note: macOS and Linux may behave differently for setgid on directories — test on your target OS.

How to use

  1. Enter an octal (e.g. 755, 644, 4755) or click a preset chip.
  2. Use the rwx checkbox grid to toggle individual bits. The octal and symbolic forms update together.
  3. Copy the chmod or find command from the output panel.

About this tool

Show

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