About chmod Decoder
chmod Decoder works in the opposite direction from the calculator: you give it a three-digit octal value and it tells you which permissions that value grants. Enter 755 and it shows that the owner has read, write and execute, while the group and everyone else have read and execute. It is the quickest way to make sense of a permission string you have inherited from a config file, a tutorial or a colleague.
The decoding is a matter of splitting each digit into its three parts. Because read is 4, write is 2 and execute is 1, every number from 0 to 7 corresponds to exactly one combination of those three flags — 5 is read plus execute, 3 is write plus execute, and so on. The tool works through all three digits and lays the result out as the familiar rwx notation, using a dash for any permission that is absent.
One practical point is that the input is interpreted as octal, not as an ordinary decimal number. That matters because 755 means seven-five-five, and the digit 8 or 9 is simply not a valid octal digit. A value containing them is rejected rather than silently misread, which is exactly what you want when the number is going to determine who can read or modify a file.
How to use chmod Decoder
- 1 Type a three-digit octal value such as 755 into the input box.
- 2 Read the permission breakdown, which updates as you type.
- 3 Use the rwx output to understand, document or set the file permissions.
Frequently asked questions
What does 755 actually grant?
The owner gets read, write and execute, shown as rwx; the group and everyone else get read and execute, shown as r-x. That is the standard mode for directories and programs.
Why can't I enter 888?
chmod values are octal, so each digit runs from 0 to 7. An 8 or 9 is not a valid octal digit and the tool reports the value as invalid rather than guessing.
What does the dash in the output mean?
A dash stands for a permission that is not granted. In r-x the middle dash is the missing write bit, so that group can read and execute but cannot modify the file.
Can it decode a four-digit value?
The tool reads what you give it, and a leading digit such as the 4 in 4755 is the setuid, setgid or sticky portion. The three trailing digits still describe the read, write and execute flags for owner, group and everyone else.
Free, online, and private
Free to use
chmod Decoder is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How chmod Decoder behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Input | a single line of text that is passed through parseInt(value, 8) — anything JavaScript reads as digits 0 to 7, with no length check |
| Output | three lines, `Owner: rwx`, `Group: rwx`, `Other: rwx`, each rendered as exactly three characters |
| Missing bits | an unset bit is written as a literal hyphen, so 644 prints Owner: rw-, Group: r--, Other: r-- |
| Bit extraction | owner is (value >> 6) & 7, group is (value >> 3) & 7, other is value & 7 |
| Sample | 755 |
Compiled from the implementation of this tool and checked against it by itoolnet.
What chmod Decoder does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- A four-digit value must not be pasted in. parseInt reads 0755 as 493 while the shifts still see 755, so Owner comes back as r-x instead of rwx, and the sticky or setuid bit it was meant to carry is dropped without any indication in the output.
- There is no length check, so a digit that does not fit in three bits is silently discarded: 7777 and 1777 both decode to the same three lines, and the fourth digit is never reported anywhere on the page.
- The output is bare rwx triads. Names such as u, g and o are not spelled out, the numeric value that was read is not echoed back, and directories are not distinguished from ordinary files even though the x bit means something different for each.
- Incomplete input is accepted rather than rejected. parseInt reads the leading digits and stops at the first character it does not recognise, so 64 comes back as three perfectly ordinary lines and 7x5 decodes as though it were 7 — the only visibly wrong answer is text that yields NaN, which prints the generic Invalid chmod line.
Tested and documented by itoolnet, the team that builds and maintains this site.