Skip to content
BSWEN
Blog

When Should You Escape Curly Braces in Regular Expressions?

Cowrie
Cowrie
Dev @ Bswen

Problem

I was writing a regex pattern to match JSON-like strings containing curly braces, and I got unexpected results. In JavaScript, my pattern failed:

Pattern: {id:\d+}
Input: {id:123}
Result: No match (unexpected!)

But when I tried the same pattern in a different context, it sometimes worked. What’s going on?

Environment

  • JavaScript (Node.js 20.x)
  • Python 3.x
  • Bash grep (GNU grep 3.x)
  • PCRE (Perl Compatible Regular Expressions)

The Root Cause

I discovered that curly braces { and } have special meaning in regex - they define quantifiers like {2,5} meaning “match 2 to 5 times.” This creates ambiguity when you want to match a literal curly brace character.

Here’s what I tried first in JavaScript:

test.js
const pattern = /{id:\d+}/;
const text = "{id:123}";
console.log(pattern.test(text)); // What do you expect?

The result:

false

Wait, why doesn’t it match? The pattern looks correct - I want to match literal {, then id:, then digits, then literal }.

What I Tried First

I thought maybe the regex engine was treating {id as a quantifier. Let me test with a simpler case:

test.js
const pattern1 = /{abc}/;
const pattern2 = /{2}/;
const pattern3 = /a{2}/;


console.log("{abc} matches pattern1:", pattern1.test("{abc}"));
console.log("{2} matches pattern2:", pattern2.test("{2}"));
console.log("aa matches pattern3:", pattern3.test("aa"));

The output surprised me:

{abc} matches pattern1: true
{2} matches pattern2: false
aa matches pattern3: true

Interesting! Pattern1 works because {a isn’t valid quantifier syntax (quantifiers need digits). Pattern3 shows that {2} IS interpreted as a quantifier (matching two ‘a’ characters). Pattern2 fails because {2} without a preceding pattern is invalid quantifier syntax.

The Solution: Always Escape

I found the safest approach is to always escape curly braces when you want them literally:

test.js
// Escape both braces for consistency
const pattern = /\{id:\d+\}/;
const text = "{id:123}";
console.log(pattern.test(text)); // true

Output:

true

This works because \{ tells the regex engine “treat this as a literal { character, not as the start of a quantifier.”

How Different Regex Flavors Handle This

I tested across multiple environments to understand the variation.

JavaScript

JavaScript’s regex engine (V8) follows these rules:

javascript-test.js
// Valid quantifier syntax - requires escaping
/\d{2}/.test("12");     // true - matches exactly 2 digits
/\d{2,5}/.test("123");  // true - matches 2-5 digits


// Invalid quantifier syntax - treated as literal
/{abc}/.test("{abc}");  // true - {a is not valid quantifier
/{id}/.test("{id}");    // true - {i is not valid quantifier


// Ambiguous cases - escape for safety
/\{id\}/.test("{id}");   // true - always safe

Python

Python’s re module has similar behavior:

test.py
import re


# Quantifier syntax
print(re.search(r'\d{2}', "12"))      # Match
print(re.search(r'\d{2,5}', "123"))   # Match


# Invalid quantifier - treated as literal
print(re.search(r'{abc}', "{abc}"))  # Match


# Safe approach - always escape
print(re.search(r'\{id:\d+\}', "{id:123}"))  # Match

Output:

<re.Match object; span=(0, 2), match='12'>
<re.Match object; span=(0, 3), match='123'>
<re.Match object; span=(0, 5), match='{abc}'>
<re.Match object; span=(0, 8), match='{id:123}'>

Bash grep

Bash adds another layer of complexity because the shell also uses curly braces for expansion:

test.sh
# WRONG: Shell expands {a,b} to "a b" before grep sees it
echo "{id:123}" | grep "{id:[0-9]*}"


# CORRECT: Use single quotes to prevent shell expansion
echo "{id:123}" | grep '{id:[0-9]*}'


# SAFEST: Escape in the regex itself
echo "{id:123}" | grep '\{id:[0-9]*\}'

Output:

# Without proper escaping, you might get:
grep: brace argument: No match


# With proper escaping:
{id:123}

PCRE (grep -P)

Using Perl-compatible regex:

pcre-test.sh
echo "{id:123}" | grep -P '\{id:\d+\}'

Output:

{id:123}

Why This Matters

I learned the hard way that inconsistent escaping causes real problems:

  1. Script portability: My regex worked in Python but failed in a bash script
  2. Debugging difficulty: The error messages are often cryptic
  3. Silent failures: Sometimes the pattern just doesn’t match with no error

Here’s a real bug I encountered:

buggy_parser.py
import re


def parse_json_fragment(text):
    # BUG: Doesn't escape braces
    pattern = r'^{name:"[^"]+"}$'
    return bool(re.match(pattern, text))


# This works by accident!
parse_json_fragment('{name:"test"}')  # Returns True


# But this fails
parse_json_fragment('{id:123}')       # Returns False (but should it?)

The issue is that {n happens to not be valid quantifier syntax, so it’s treated as literal. But {id:123} might behave differently depending on the regex engine.

The fix:

fixed_parser.py
import re


def parse_json_fragment(text):
    # FIX: Always escape braces for safety
    pattern = r'^\{name:"[^"]+"\}$'
    return bool(re.match(pattern, text))

The Implementation Variation Problem

I discovered that different implementations handle edge cases differently:

Pattern: ^{status:(active|inactive)}$


| Engine    | Matches "{status:active}"? | Notes                         |
|-----------|----------------------------|-------------------------------|
| JavaScript| Yes (sometimes)            | Depends on exact pattern      |
| Python    | Yes                        | {s not valid quantifier       |
| PCRE      | Warning/Error              | Stricter parsing              |
| POSIX ERE | Yes                        | {s not valid quantifier       |

This inconsistency is why escaping is the recommended practice.

Common Mistakes I Made

Mistake 1: Assuming position matters

I thought a leading { couldn’t be a quantifier because there’s nothing before it to quantify:

mistake1.js
// I assumed this was safe - it's at the START of the pattern
const pattern = /^{id:\d+}$/;


// But some engines still complain or behave unexpectedly

While logically true (you can’t quantify nothing), some regex engines still require escaping.

Mistake 2: Forgetting to escape the closing brace

I escaped { but forgot }:

mistake2.js
// WRONG: Only escaped opening brace
const pattern = /\{id:\d+}/;


// In some contexts, this can cause issues
// CORRECT: Escape both
const pattern = /\{id:\d+\}/;

Mistake 3: Mixing shell and regex escaping

In bash scripts, I confused shell escaping with regex escaping:

mistake3.sh
# WRONG: Confusion between shell and regex escaping
grep "\\{id:[0-9]+\\}" file.txt


# The shell processes \\{ first, then grep sees \{
# This might work but is confusing


# BETTER: Use single quotes for shell, escape in regex
grep '\{id:[0-9]\+\}' file.txt

A Practical Example

Here’s a complete example showing the safe approach:

safe_regex.py
import re


def extract_braced_content(text):
    """
    Extract content like {variable} from text.
    Uses escaped braces for safety across environments.
    """
    # Always escape braces - works everywhere
    pattern = r'\{([a-zA-Z_][a-zA-Z0-9_]*)\}'
    matches = re.findall(pattern, text)
    return matches


# Test cases
text = "Hello {name}, your id is {user_id} and status is {status}"
variables = extract_braced_content(text)
print(variables)

Output:

['name', 'user_id', 'status']

Summary

Curly braces in regex define quantifier syntax {m,n}, so they must be escaped when you want to match them literally. While some regex engines treat { as literal when followed by a non-digit (invalid quantifier syntax), this behavior is inconsistent across implementations. The safest approach is to always escape both braces: \{ and \}. This ensures your patterns work reliably in JavaScript, Python, PCRE, POSIX ERE, and other regex flavors without surprising you with “no match” results or silent failures.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: