Chmod Calculator

chmod 755 sets the following permissions: Owner can read, write, and execute (7 = rwx); Group can read and execute (5 = r-x); Others can read and execute (5 = r-x). This is the standard permission for executable scripts and public directories on web servers. The owner has full control, while everyone else can read and execute but not modify.

Octal notation uses three digits (e.g., 755) where each digit represents the sum of permission values: read=4, write=2, execute=1. Symbolic notation uses letters (e.g., rwxr-xr-x) where r=read, w=write, x=execute, and - means no permission. Both represent the same permissions — octal is faster to type, symbolic is easier to read. This tool converts between them instantly.

644 (rw-r--r--) is standard for files: owner can read/write, everyone else read-only. 755 (rwxr-xr-x) is standard for directories and scripts: owner has full access, others can read/execute. 600 (rw-------) is for private files like SSH keys: only owner can read/write. 777 (rwxrwxrwx) gives everyone full access and should be avoided for security reasons.

Special permissions are represented by a fourth octal digit prepended to the standard three: setuid (4) runs executables as the file owner, setgid (2) runs them as the group owner or inherits group on directories, and sticky bit (1) prevents deletion by non-owners in shared directories like /tmp. For example, chmod 1755 adds the sticky bit to standard 755 permissions.

No. This tool calculates Unix/Linux file permissions (POSIX). Windows uses a different permission system based on Access Control Lists (ACLs) with user/group SIDs. If you are on Windows using WSL (Windows Subsystem for Linux), chmod commands work within the WSL filesystem.

777 makes a file readable, writable, AND executable by everyone, which is both a security hole and often not the actual problem. The danger: world-writable files let ANY user or process on the system modify them — for a web server's files, that's a direct path to compromise (an attacker who gets any foothold can overwrite your code). The reason it frequently doesn't fix the error is that 'permission denied' is usually about OWNERSHIP or a DIRECTORY along the path, not the file's mode — if the web server runs as www-data but the file is owned by you with no group access, or if a parent directory lacks the execute (traverse) bit, 777 on the file alone won't help. The correct fix is almost always proper ownership (chown) plus sane modes: 644 for files, 755 for directories — never reach for 777 as a debugging shortcut.

It means completely different things. On a FILE, the execute bit (x) makes it runnable as a program or script. On a DIRECTORY, x is the 'traverse' or 'enter' permission — it controls whether you can cd INTO the directory and access files inside it by name. This is the source of countless bugs: a directory with read (r) but no execute (x) lets you LIST the filenames but not actually open any of them; a directory with execute but no read lets you access a file IF you know its exact name but not list the contents. That's why directories normally need 755 (rwxr-xr-x) — everyone needs the x bit to traverse into them — while files only need 644 (rw-r--r--). Removing x from a directory in a path is a classic cause of mysterious 'permission denied' on files that look perfectly readable.