Toolvore

Chmod Calculator

Convert between symbolic and octal Unix file permissions.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Each digit of a Unix mode is the sum of read 4, write 2 and execute 1 for one audience — owner, group, then everyone else — and this calculator moves between that number, the nine rwx letters ls -l shows, and the chmod command.

How to use it

  1. 1Type a mode into the Octal box, or tick Read, Write and Execute for Owner, Group and Others — the grid and the number stay in step.
  2. 2Read the symbolic form beside the box and the chmod line in the dark bar below it.
  3. 3Start from a preset — 777, 755, 644, 600, 4755, 1777 — if you would rather adjust a known mode than build one.

Example

Input
755
Output
rwxr-xr-x — chmod 755 filename

The decision most people arrive with is 644 or 755, and it turns on what the execute bit means for the thing you are setting. On a file it means 'this can be run'; on a directory it means 'this can be entered and what is inside reached'. So a directory wants 755 even though nothing in it is a program, while an ordinary file wants 644 — and a script that will not run despite sitting on your PATH usually got 644 by mistake. A fourth digit in front carries the special bits, setuid 4, setgid 2 and sticky 1, so 4755 shows rwsr-xr-x and 1777 the rwxrwxrwt that /tmp carries. That letter turns capital when the special bit is set without the matching execute bit, so 4644 reads rwSr--r--, nearly always an accident.

What happens to your data

This tool runs entirely in your browser. Your input is never uploaded to a server, never stored, and never logged. Nothing is executed and no filesystem is touched: the tool is bitwise arithmetic on three or four digits, and the path you mean to change is never typed here — the command says the word filename literally, for you to replace. Octal only goes in, so u+x is refused, as is any digit above 7, and a refusal leaves the last valid mode on screen rather than a command for a mode you never saw.

Last updated August 2026

The deploy script you pulled off the server will not run. Or a web server answers 403 for a directory you can list perfectly well in your own shell, or ssh refuses a key it accepted yesterday. Each is the same class of problem: something on disk carries a mode you cannot read at a glance, and the fix is a three-digit number you half remember.

Decide first whether you want the numeric form or the symbolic one. chmod 644 is absolute — it sets all nine bits and discards whatever was there. chmod u+x is relative — it adds one permission and leaves the rest untouched. Numeric is right when you know the whole mode you are aiming at; symbolic is right when you are adding execute to a file someone else set up and would rather not disturb its group settings.

What the format cannot express is worth knowing first. There are three audiences and no more, with no slot for a second named user: if one colleague needs write access and another does not, the mode cannot say so. That needs a shared group, or a POSIX ACL, which sits outside the mode and shows as a trailing plus in ls -l.

The mistake that costs the most time is fixing the file and forgetting the path to it. Reaching a file means holding execute on every directory above it, so a readable 644 file inside a 700 folder is unreachable for everyone but its owner.

How it works

Toolvore is bitwise arithmetic on three or four small numbers. The grid and the octal box are two views of one state: ticking a checkbox flips a single bit in that role's digit with an exclusive or, and the text field is rewritten from the digits on every change, so the number and the letters cannot drift apart. Typing is parsed strictly — exactly three digits of 0 to 7, or exactly four, where the leading one carries setuid, setgid and sticky, and the field stops at four characters. A three-digit entry clears any special bits you had, which catches people who type 755 over the 4755 preset. Its weakness is that it translates rather than inspects: it cannot tell what mode your file carries now, whether you own it, or whether an ACL, a noexec mount or SELinux will overrule the result. The symbolic string is display only, and it is the nine permission characters alone, without the leading d or dash that ls -l prints in front.

Common use cases

  • Setting a deploy script executable without opening it to everyone
  • Getting a private key to 600 before ssh will accept it
  • Rebuilding a mode read out of an ls -l listing
  • Checking what the leading 4 in 4755 grants
  • Fixing a 403 on files written by another process
  • Writing a chmod line into a Dockerfile
  • Explaining why /tmp is 1777

Frequently asked questions

Why does my shell script say Permission denied?

Three separate causes wear the same message. The file may lack the execute bit for you in particular — 644 is the usual culprit, and 755 or 700 clears it. Or the file is fine but a directory on the way to it is not, since entering a directory requires execute on it, so a script inside a 600 folder is unreachable whatever its own mode says. Or the filesystem is mounted noexec, common on /tmp and removable media. A broken shebang gives a different complaint, about a bad interpreter, which rules the mode out.

What does chmod 777 actually do, and why do people warn against it?

It grants read, write and execute to the owner, to the group and to every other account on the machine. Anyone who can log in can rewrite the file, and if something else runs that file, they decide what it does. It is usually reached for as a debugging move — rule permissions out by opening everything — and then never reverted. When 777 appears to fix a problem, the real fault is nearly always ownership: the process doing the work runs as a user that is neither the owner nor in the file's group.

What is the difference between chmod and chown?

They answer different halves of one question. chown sets which user and group own a file, and that decides which of the three columns applies to you when you touch it. chmod sets what each column may do. Neither is much use without the other — granting group write does nothing for a colleague outside the group, and moving a file into the right group does nothing while the group column allows only reading. Ordinary users cannot hand a file to someone else, so chown usually needs root, while chmod is available to whoever owns the file.

How do I set 755 on directories and 644 on files in one pass?

Two find commands is the plain way: find path -type d -exec chmod 755 {} + and find path -type f -exec chmod 644 {} +. Running chmod -R 755 over the tree instead is the classic error, because it marks every ordinary file executable, images and configuration included. To do it in one command, the symbolic form has a capital X meaning execute only where the target is a directory or already carries execute for somebody: chmod -R u=rwX,go=rX. A number cannot express that, since it applies the same bits to everything it touches.

Why do new files come out as 644 when I never chose that?

That is your umask. Programs ask for a mode when they create something — conventionally 666 for a file and 777 for a directory — and the kernel removes whatever bits the umask names. The widespread default is 022, leaving 644 for files and 755 for directories. Files start from 666 rather than 777, which is why a new file is never executable however permissive your umask is. A umask applies only to things made after it is set and is inherited per process, so setting it in your shell does not reach a daemon started at boot.

What does the sticky bit do on a directory?

It restricts deletion. Removing or renaming a file is a write to the directory rather than to the file, so in an ordinary world-writable directory anybody could delete anybody else's work no matter how the file itself was protected. With the sticky bit set, only the file's owner, the directory's owner or root can remove or rename an entry. That is why /tmp is 1777: everyone needs to write there, and nobody should be able to clear out someone else's session files. On ordinary files the bit does nothing useful on modern systems.

Why does ssh refuse to use my private key?

ssh inspects the permissions itself and declines rather than use a key others could read. The key file wants 600, the ~/.ssh directory 700, and your home directory must not be group or world writable — a home at 775 triggers the refusal even when the key itself is correct. The warning names the key file, which makes it easy to fix that and miss the directory above it. The same strictness applies on the server to authorized_keys, which is why a key that looks installed is ignored at login.

Is it safe to use an online chmod calculator for a production server?

Here, yes, because nothing leaves the page. The calculator is three digits and a special-bits number held in the component's own state, with exclusive or and bitwise and doing all the work — there is no request to anywhere and no file is read or written. Nothing is executed either: what you get back is text you copy and run yourself. The generated line says the word filename literally rather than asking for your path, so the one genuinely sensitive detail — where the file lives — is never typed at all.