A system is case-sensitive if it distinguishes between uppercase and lowercase versions of the same letter. In a case-sensitive system, 'A' and 'a' are two completely different characters with different values — the same way '1' and '2' are different.

A system is case-insensitive if it treats uppercase and lowercase versions of the same letter as identical. In a case-insensitive system, 'A' and 'a' are the same character — either form matches the other.

At the computer's lowest level, every character has a numeric code (its ASCII or Unicode value). Uppercase 'A' is code 65; lowercase 'a' is code 97. They are different numbers. A case-sensitive system compares these numbers directly. A case-insensitive system converts both to the same form before comparing — usually both to lowercase — so 65 and 97 both become 97 before the check runs.

Passwords are universally case-sensitive. 'Password1' and 'password1' and 'PASSWORD1' are three different passwords that will not authenticate each other.

This is intentional and important for security. If passwords were case-insensitive, an attacker guessing passwords would need to try half as many combinations — because they wouldn't need to consider which letters were uppercase. Case sensitivity doubles the search space for each letter in the password, making brute-force attacks significantly more difficult.

This is why Caps Lock is a notorious password trap. A user who types their password with Caps Lock on is entering entirely different characters than they intend. Most password fields show a Caps Lock warning for exactly this reason.

When storing passwords, good systems don't store the actual password at all — they store a hash of the password. That hash is computed from the exact characters entered, including their case. So the system never needs to 'compare' passwords in a case-insensitive way even if it wanted to — the hash of 'Password1' and the hash of 'password1' are completely different values.

Whether your file system is case-sensitive depends on which operating system you are using — and the answer is different from what most people expect.

Linux: Case-sensitive by default. 'README.md', 'readme.md', and 'Readme.md' are three different files that can coexist in the same directory. This catches many developers off guard when code that works on their Mac fails on a Linux server.

macOS: Case-insensitive but case-preserving by default. The file system remembers how you named a file ('README.md') and displays it that way, but it will not let you create 'readme.md' in the same folder — and looking up 'readme.md' returns 'README.md'. You can optionally format a Mac volume to be case-sensitive, but most users never do.

Windows: Case-insensitive by default, same as macOS. 'README.md' and 'readme.md' are treated as the same file. Windows also preserves the original casing in display.

This difference between Linux and macOS/Windows causes a real and common bug: a developer writes import statements on a Mac with the wrong case — say, importing './Components/button' when the file is './components/Button.tsx' — and it works on their machine (macOS is case-insensitive, so the wrong case still resolves). The same code then breaks in production on a Linux server, where the wrong case finds nothing.

URLs have a split personality when it comes to case sensitivity: the domain name is case-insensitive, but the path (everything after the domain) is technically case-sensitive.

Domain names are always case-insensitive. 'Google.com', 'GOOGLE.COM', and 'google.com' all reach the same server — the DNS system that resolves domain names treats them as case-insensitive.

URL paths are case-sensitive by the HTTP specification. '/Blog/My-Post' and '/blog/my-post' are technically different URLs that can serve different content or return different error codes. In practice, many web servers (especially on Windows hosting) are configured to be case-insensitive for paths. But on Linux-based servers — which host the majority of the web — paths are case-sensitive.

This is why best practice for web URLs is to use all-lowercase paths consistently. A URL like '/Blog/My-Post' might work on your development server but silently break on production, or create duplicate content issues if both the capitalized and lowercase versions resolve to the same page.

Most programming languages are case-sensitive — meaning 'myVariable', 'MyVariable', and 'MYVARIABLE' are three completely different identifiers that have no relationship to each other.

• ▸Case-sensitive languages: Python, JavaScript, TypeScript, Java, C, C++, C#, Go, Rust, Ruby, Swift — the vast majority of modern languages
• ▸Case-insensitive languages: SQL keywords (SELECT and select are equivalent), Visual Basic, older BASIC variants, some configuration file formats
• ▸Case-insensitive for specific elements: HTML tag names and attributes (both <DIV> and <div> are valid), CSS property names

In SQL, the keywords are case-insensitive (SELECT, select, and Select all work), but table names and column names depend on the database engine and its configuration. MySQL on Linux is case-sensitive for table names by default; MySQL on Windows is case-insensitive. PostgreSQL is case-insensitive for unquoted identifiers but case-sensitive for quoted ones.

The practical consequence for developers: when switching between languages, never assume case handling carries over. JavaScript variable names are case-sensitive; an HTML attribute name is not. A Python import is case-sensitive; a Windows file path lookup is not. These inconsistencies are a frequent source of cross-platform bugs.