How to Use UPPER and LOWER in SQL

Use UPPER() and LOWER() when text needs consistent letter casing for display, normalization, search matching, or cleanup. These functions are especially useful for emails, tags, names, and case-insensitive comparisons.

What you’ll build or solve

You’ll learn how to use UPPER and LOWER in SQL to normalize text casing. You’ll also know when to use them for search logic versus display formatting.

When this approach works best

This approach is the right choice when inconsistent letter casing causes duplicate-looking values or unreliable filters.

Common real-world scenarios include:

• Normalizing emails
• Standardizing tags
• Case-insensitive search
• Export formatting
• Uppercase country codes

This is a bad idea when the original casing must remain untouched for brand or legal display rules.

Prerequisites

You only need:

• A SQL table with text columns
• Basic SELECT and WHERE knowledge

Step-by-step instructions

Step 1: Wrap the text column in UPPER() or LOWER()

Use UPPER() for uppercase output.

SELECT UPPER(country_code) AS code
FROM offices;

Use LOWER() for lowercase output.

SELECT LOWER(email) AS normalized_email
FROM users;

This is especially useful in comparisons.

SELECT *
FROM users
WHERE LOWER(email) = 'alex@example.com';

This makes matching consistent even if stored casing varies.

What to look for:

• UPPER() converts all letters to uppercase
• LOWER() converts all letters to lowercase
• Great for normalization
• Useful in search filters
• May affect index usage in some databases

Examples you can copy

Lowercase emails

SELECT LOWER(email)
FROM users;

Uppercase country codes

SELECT UPPER(country_code)
FROM locations;

Case-insensitive search

SELECT *
FROM products
WHERE LOWER(name) = 'keyboard';

Common mistakes and how to fix them

Mistake 1: Changing display casing unintentionally

What the reader might do:

SELECT UPPER(brand_name)
FROM brands;

Why it breaks: this may damage intended brand styling.

Corrected approach:

Use it only for normalization or matching, not branded UI text.

Mistake 2: Applying it only on one side of comparisons

What the reader might do:

WHERE LOWER(email) = input_email

Why it breaks: the input may still have mixed casing.

Corrected approach:

Normalize both sides.

WHERE LOWER(email) = LOWER(input_email)

Mistake 3: Overusing it in indexed filters

What the reader might do:

WHERE LOWER(email) = 'alex@example.com'

Why it breaks: function-wrapped columns may bypass normal indexes.

Corrected approach:

Use functional indexes or normalized stored values when performance matters.

Troubleshooting

If matches still fail, normalize both sides of the comparison.

If performance drops, check index usage.

If UI text loses branding, avoid changing display casing.

If values should stay normalized permanently, consider storing lowercase values.

Quick recap

• Use UPPER() for uppercase
• Use LOWER() for lowercase
• Great for normalization and matching
• Normalize both sides of comparisons
• Watch index performance in large tables