Performance | Toolbox Guides & Articles

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

RegEx Tester & Group Matcher

Toggle the g, i, m, s, and u flags live, inspect every capture group, and read a token-by-token explanation of what your pattern actually does.

Open RegEx Tester & Explainer →

Two Kinds of Regex Engine

Not all regex implementations share the same performance model, and the difference decides whether a pattern can be attacked.

	Backtracking (NFA)	Automaton (DFA/RE2)
Used by	JavaScript, Python `re`, Java, PCRE, .NET, Ruby	Go `regexp`, Rust `regex`, RE2, `grep -E`
Worst case	Exponential in input length	Linear in input length
Backreferences	Supported	Not supported
Lookaround	Supported	Not supported
Attackable	Yes	No

The trade is explicit: backtracking engines buy backreferences and lookaround at the cost of a worst-case time bound. JavaScript uses a backtracking engine, so every pattern you run against untrusted input carries a performance contract you need to understand.

How Backtracking Actually Fails

Take the pattern ^(a+)+$ and the input aaaa!.

The inner a+ is greedy, so it consumes all four a characters.
The outer + tries to repeat; there is nothing left, so it stops.
$ is checked. The next character is !, not end-of-string. Fail.
The engine backtracks: what if the inner a+ had taken three characters and the outer group repeated to take the fourth?
Fail again. What about 2 + 2? 2 + 1 + 1? 1 + 3? 1 + 1 + 2? 1 + 1 + 1 + 1?

Each of those is a distinct partition of the input, and every one must be tried before the engine can report no match. The number of ways to partition n items into ordered groups grows as 2^(n-1).

Input Length	Partitions Explored	Approximate Time
20	~524,000	milliseconds
25	~16.7 million	~0.1 seconds
30	~536 million	several seconds
35	~17 billion	minutes
40	~550 billion	hours

Add five characters, take thirty-two times longer. That is the entire mechanism behind ReDoS.

The critical precondition: the overall match must fail. A pattern that matches successfully finds its answer on the first greedy pass. This is why a vulnerable pattern looks perfectly fast in tests using valid inputs, and only detonates on malformed data — which is exactly what an attacker supplies.

The Three Vulnerable Shapes

Almost every real ReDoS reduces to one of three structures.

1. Nested Quantifiers

/^(a+)+$/ // quantifier inside a quantified group
/^(\d+)*$/
/^([a-z]+)+$/

The outer repetition and the inner repetition compete for the same characters. Ambiguity is the fuel.

2. Overlapping Alternation Under a Quantifier

/^(a|aa)+$/ // both branches match the letter a
/^(\w|\d)+$/ // \w already includes \d
/^(\s|\t|\n)*$/ // \s already includes \t and \n

If two branches can match the same text, the engine has two routes to every position, doubling the search space at each step.

3. Greedy Dot-Star Next to a Similar Pattern

/^(.*),(.*)$/ // both sides compete for every comma
/<div>(.*)<\/div>/ // .* happily crosses tag boundaries
/^(.*?)(.*?)(.*?)$/ // three lazy groups over one string

. matches almost everything, including the delimiter you are trying to find, so the engine must try every split point.

The Real-World Case

On 2 July 2019, Cloudflare’s global network returned HTTP 502 errors for roughly 30 minutes. The published post-mortem attributes the outage to a newly deployed WAF rule containing .*(?:.*=.*) — a nested greedy quantifier that consumed CPU across every machine in the fleet. One regular expression, global outage. The pattern shape above is not academic.

The Rewrites That Fix It

Replace nested quantifiers with a single one

/^(a+)+$/ // vulnerable
/^a+$/ // equivalent, linear

Ask what the outer quantifier adds. In the majority of vulnerable patterns, the answer is nothing.

Make alternation branches mutually exclusive

/^(a|aa)+$/ // vulnerable — branches overlap
/^a+$/ // same language, no ambiguity

/^(\w|\d)+$/ // vulnerable — \w contains \d
/^\w+$/ // same language

Swap greedy dots for negated character classes

/"(.*)"/ // dot crosses the closing quote and backtracks
/"([^"]*)"/ // cannot cross the delimiter at all — no ambiguity

This single substitution — [^delimiter]* instead of .* — is the highest-value change in practice. It also usually fixes the correctness bug where a greedy pattern swallowed two fields.

Emulate atomic groups with a lookahead

JavaScript has no atomic groups (?>...) and no possessive quantifiers a++. You can simulate them with a lookahead plus a backreference, which discards the inner group’s backtracking positions:

// Atomic equivalent of (?>\d+)
const atomic = /(?=(\d+))\1/;

The lookahead matches greedily, the backreference consumes exactly that text, and the engine cannot revisit the choice.

Bound the input before matching

const MAX = 512;

function safeTest(pattern, input) {
 if (typeof input !== 'string' || input.length > MAX) return false;
 return pattern.test(input);
}

Even an exponential pattern is harmless on 512 bytes. A length cap is a blunt instrument, but it is the one mitigation that works without understanding the pattern — apply it at every trust boundary.

Flags Worth Knowing

The tester exposes the five flags that matter most day to day:

Flag	Name	Effect	Gotcha
`g`	Global	Find all matches	Mutates `lastIndex` — see below
`i`	Ignore case	Case-insensitive matching	Unicode case folding needs `u`
`m`	Multiline	`^` and `$` match line boundaries	Does not change what `.` matches
`s`	DotAll	`.` also matches newlines	ES2018
`u`	Unicode	Pattern read as code points; enables `\p{...}`	Makes some previously legal escapes errors

ECMAScript also defines y (sticky), d (hasIndices, ES2022), and v (set notation, ES2024).

The `lastIndex` Trap

A regex literal with g carries mutable state. Reusing one across calls produces alternating results:

const re = /\d+/g;

re.test('123'); // true — lastIndex is now 3
re.test('123'); // false — resumes from index 3, finds nothing
re.test('123'); // true — lastIndex reset to 0 after the failure

Use a non-global regex for test, create the regex inside the function, or reset re.lastIndex = 0 before each use. The same hazard applies to exec in a loop — which is the intended use of g, but only when the loop consumes matches until null.

Detection and Tooling

Static analysis catches most real cases before deployment:

eslint-plugin-regexp with the no-super-linear-backtracking rule flags exponential and polynomial patterns in CI.
recheck performs both static and fuzzing-based analysis and reports an attack string.
Dependency advisories matter too: ReDoS reports against popular parsing and validation libraries are common, so keep npm audit in your pipeline.

Runtime containment for patterns you cannot rewrite — user-supplied search expressions, for instance:

Run matching in a worker thread you can terminate on a timeout. JavaScript regex evaluation is synchronous and uninterruptible on the main thread, so this is the only way to enforce a deadline.
Use a linear-time engine via bindings such as node-re2, accepting the loss of backreferences and lookaround.
Never compile a pattern supplied by a user without both of the above.

Step-by-Step: Diagnosing a Pattern with Toolbox

Open the tool: visit the .
Start from a preset or paste your own pattern into the pattern field.
Toggle the flags — g, i, m, s, u — and watch the match set change, which is the fastest way to confirm a flag is the actual cause of a bug.
Read the token explanation. The explainer breaks the pattern into tokens, which makes nested quantifiers and overlapping alternations visible rather than buried in punctuation.
Inspect capture groups against your sample text to verify indices and named groups resolve as expected.
Test the failure case, not the success case. Paste input that nearly matches — the right prefix with one wrong character at the end. Slow, vulnerable patterns only reveal themselves when the match fails.

Everything is evaluated by your browser’s own RegExp implementation, so test data never leaves the device — which matters when the sample text is a production log line or a customer record.

For the adjacent problem of validating structured text rather than free-form strings, is usually the better tool than a regular expression.

FAQ

Frequently Asked Questions

What is catastrophic backtracking? ▼

Catastrophic backtracking occurs when a backtracking regex engine must explore an exponential number of ways to divide the same input among nested quantifiers before it can conclude that no match exists. The pattern (a+)+$ against a long run of the letter a followed by an exclamation mark is the canonical example: each added character roughly doubles the work, so a string of 30 characters can take longer than a string of 29 by a full second.

What is a ReDoS attack? ▼

ReDoS, or Regular Expression Denial of Service, is an attack in which a request carries input crafted to trigger catastrophic backtracking in a server-side pattern. Because JavaScript regex evaluation is synchronous and blocks the event loop, a single such request can freeze an entire Node.js process. The Cloudflare global outage of 2 July 2019 was caused by exactly this class of bug in a WAF rule.

How do I know whether a pattern is vulnerable? ▼

Look for a quantifier applied to a group that already contains a quantifier or an alternation whose branches can match the same text, such as (a+)+, (\\s*,)*, or (.*)*. Then check whether the pattern can fail after that group, since backtracking only explodes on failure. Static analysers such as the ESLint no-super-linear-backtracking rule and the recheck library detect most real cases automatically.

Does adding an anchor fix a slow regex? ▼

Sometimes, but not reliably. Anchoring with a caret and dollar sign prevents the engine from retrying the pattern at every starting offset, which removes one polynomial factor. It does nothing about exponential blowup inside nested quantifiers, and a trailing dollar sign can make matters worse by guaranteeing the failure that triggers the full backtracking search. Restructuring the pattern is the real fix.

Should I validate email addresses with a regular expression? ▼

Not with a complex one. Full RFC 5322 address syntax is impractical to express as a maintainable pattern, and the elaborate email regexes circulating online are a frequent source of ReDoS. Use a minimal shape check such as one non-space run, an at sign, another non-space run containing a dot, then confirm the address by sending a verification message. Deliverability is the only real proof of validity.

Base64 Encoding & Data URI Architecture: The Complete Guide for Web Developers

Sat, 05 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

Base64 Encoder & Data URL Studio

Convert images, SVGs, audio, and text into RFC 2397 Data URIs and clean Base64 strings with zero server transmission.

Open Base64 Data URL Studio →

What Is Base64 Encoding?

In modern web computing, network protocols such as HTTP, SMTP (email), and JSON were originally engineered to reliably transport human-readable ASCII text rather than raw binary streams. Transmitting raw binary bytes over legacy channels often caused corrupted payloads when control characters (such as null bytes 0x00 or carriage returns 0x0D) were stripped or modified by intermediary gateways.

Base64 (standardized in IETF RFC 4648) solves this problem by encoding arbitrary binary octets into a safe, transportable alphabet consisting of exactly 64 printable ASCII characters.

The 6-Bit Chunking Mathematics

The fundamental mechanics of Base64 revolve around the least common multiple of 8 bits (the size of a standard computer byte) and 6 bits (the capacity of a 64-symbol alphabet, since $2^6 = 64$).

$$\text{LCM}(8, 6) = 24 \text{ bits}$$

Every 3 bytes of raw binary data (24 bits) are grouped together and sliced into 4 chunks of 6 bits each:

Raw Bytes (3 x 8 bits = 24 bits):
[ 01001101 ] [ 01100001 ] [ 01101110 ] -> "Man" (ASCII)
 0x4D 0x61 0x6E

Re-chunked (4 x 6 bits = 24 bits):
[ 010011 ] [ 010110 ] [ 000101 ] [ 101110 ]
 19 22 5 46

Base64 Alphabet Lookup:
 'T' 'W' 'F' 'u' -> "TWFu"

Because 3 raw bytes require 4 characters to represent, Base64 encoding inherently inflates uncompressed payload volume by:

$$\frac{4 - 3}{3} = 33.33\%$$

Padding Mechanics (`=` and `==`)

What happens when your input payload does not end on an exact 3-byte boundary? RFC 4648 dictates deterministic padding with the equals sign (=):

If 1 byte remains (8 bits): The byte is split into one 6-bit chunk and one 2-bit chunk padded with 4 zero bits. The remaining two 6-bit positions are padded with ==.
- Input: "M" (1 byte) $\rightarrow$ Base64: "TQ=="
If 2 bytes remain (16 bits): The bytes are split into two 6-bit chunks and one 4-bit chunk padded with 2 zero bits. The final 6-bit position is padded with =.
- Input: "Ma" (2 bytes) $\rightarrow$ Base64: "TWE="
If 3 bytes remain (24 bits): Exact match. Zero padding characters appended.
- Input: "Man" (3 bytes) $\rightarrow$ Base64: "TWFu"

RFC 2397 Data URI Grammar

A Data URI allows developers to embed inline data directly within document targets where a URL would typically be referenced (such as <img src="...">, url(...) in CSS, or <link rel="icon">).

The formal grammar defined in IETF RFC 2397 is:

data:[<mediatype>][;base64],<data>

Anatomical Breakdown

Scheme: Mandatory data: protocol identifier.
Media Type (MIME): Defines payload interpretation (e.g. image/png, image/svg+xml, font/woff2, application/json). If omitted, defaults to text/plain;charset=US-ASCII.
Encoding Token: Optional ;base64 flag indicating that the payload is Base64 encoded. If omitted, data is interpreted as percent-encoded URL text.
Data Payload: The encoded character string.

Practical Implementation Examples

<!-- Inlined 1x1 Transparent PNG Spacer -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=" alt="Spacer" />

<!-- Inlined SVG Icon in CSS -->
<style>
.badge-check {
 background-image: url('data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAyNCAyNCI+PHBhdGggZD0iTTkgMTYuMkw0LjggMTJsLTEuNCAxLjRMOSAxOSAyMSA3bC0xLjQtMS40TDkgMTYuMnoiLz48L3N2Zz4=');
}
</style>

Performance Architecture: When to Inline vs When to Link

Inlining everything as Base64 Data URIs is an anti-pattern. Evaluate assets according to this architectural matrix:

Evaluation Dimension	Inlined Data URI (RFC 2397)	External File Asset (`/assets/...`)
HTTP Request Count	0 requests (Embedded in parent file)	1 request per asset
Payload Size	+33% larger than raw binary	Compact raw binary byte stream
Browser Caching	Tied to parent HTML/CSS cache lifecycle	Independently cached with HTTP `Cache-Control: max-age=31536000`
HTML/CSS Parser Blocking	Bloats DOM/CSSOM parse time	Non-blocking or asynchronously loaded
Gzip / Brotli Compression	Partially compresses (~10-15% recovery)	Highly efficient dictionary compression
Optimal Use Cases	Micro SVGs (< 2KB), critical first-paint icons, email HTML templates	Photographs, large backgrounds, web fonts (> 20KB), multi-page shared assets

Character Encoding Safety: Overcoming the `btoa` Latin1 Bug

A notorious bug in web applications occurs when calling the native browser method window.btoa() on UTF-8 strings containing characters beyond code point 255:

// ❌ Throws: DOMException: Failed to execute 'btoa' on 'Window':
// The string to be encoded contains characters outside of the Latin1 range.
window.btoa("Hello, 世界! 🚀");

The RFC-Compliant Client-Side Solution

To safely encode UTF-8 strings without server roundtrips, leverage modern Web Standards (TextEncoder and Uint8Array):

function safeUtf8ToBase64(str) {
 // 1. Serialize UTF-8 string into raw binary byte array
 const utf8Bytes = new TextEncoder().encode(str);

 // 2. Convert binary bytes into a binary string
 let binaryString = "";
 for (let i = 0; i < utf8Bytes.length; i++) {
 binaryString += String.fromCharCode(utf8Bytes[i]);
 }

 // 3. Native btoa is now 100% safe
 return window.btoa(binaryString);
}

function safeBase64ToUtf8(base64) {
 const binaryString = window.atob(base64);
 const bytes = new Uint8Array(binaryString.length);
 for (let i = 0; i < binaryString.length; i++) {
 bytes[i] = binaryString.charCodeAt(i);
 }
 return new TextDecoder().decode(bytes);
}

Step-by-Step: Converting Files and Assets in Toolbox

Open the Studio: Access the .
Drag & Drop or Select Asset: Drop any PNG, JPEG, WebP, SVG, WOFF2 font, or text file directly onto the upload zone.
In-Browser Processing: The browser’s native FileReader or ArrayBuffer pipeline immediately processes the binary bytes locally in memory. No data is transmitted over the network.
Choose Format: Toggle between Raw Base64, RFC 2397 Data URL, HTML <img> tag, or CSS background-image snippet.
Inspect Live Preview & Payload Stats: View the before-and-after byte volume and size inflation calculation in real-time.
Copy Snippet: Click Copy to Clipboard with one touch.

Interactive Workbench LIVE

Base64 Encoding & Data URI Architecture: The Complete Guide for Web Developers

Open Fullscreen ↗

Convert images, SVGs, audio, and text into RFC 2397 Data URIs and clean Base64 strings with zero server transmission.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

Why does Base64 encoding increase file size by ~33%? ▼

Base64 represents binary data using only 64 printable ASCII characters. Because each character stores only 6 bits of information instead of the full 8 bits of a standard byte, 3 raw bytes (24 bits) require 4 Base64 characters (4 * 6 = 24 bits) to transmit. This 4/3 ratio creates an inherent mathematical 33.33% payload expansion.

Why does window.btoa() throw an error on emojis and special characters? ▼

The browser's native window.btoa() API only supports 8-bit Latin1 (ISO-8859-1) characters (code points 0x00 to 0xFF). Multibyte UTF-8 characters like emojis, accented letters, or non-Latin scripts contain code points above 255, causing btoa() to throw 'InvalidCharacterError'. Modern apps must use TextEncoder with Uint8Array to properly serialize UTF-8 before Base64 encoding.

When should I inline assets with Data URIs versus linking external files? ▼

Data URIs are ideal for tiny, critical assets (sub-2KB SVG icons, micro logo badges, or above-the-fold placeholder blurs) where eliminating an HTTP request roundtrip outweighs the 33% payload penalty. For larger assets, external files are superior because browsers can cache them independently, parallelize downloads over HTTP/2, and avoid CSS parser blocking.

What is the difference between standard Base64 and Base64URL? ▼

Standard Base64 (RFC 4648 §4) uses '+' and '/' as characters 62 and 63, with '=' for padding. These characters have special syntactic meanings in URL query parameters and filenames. Base64URL (RFC 4648 §5) replaces '+' with '-' (minus) and '/' with '_' (underscore), and typically omits padding '=' to ensure URL and filesystem safety.

How to Compress Images to 100KB, 200KB, or 500KB Online (Without Quality Loss)

Fri, 04 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

Compress Image to Exact Target Size

Select your target size (50KB, 100KB, 200KB, 500KB) and compress photos instantly in memory with zero quality degradation.

Compress Image to 200KB Now →

Why Exact File Size Compression Matters

Whether applying for government examinations, university admissions portals, visa applications, or optimizing web performance for Google Core Web Vitals, rigid file size limits are ubiquitous:

Passport & Visa Portals: Frequently reject photos larger than 200KB or 100KB.
Job Applications & KYC Systems: Restrict ID card scans to 500KB.
Mobile Web Performance: Keeping hero images under 150KB is vital for passing Largest Contentful Paint (LCP) benchmarks.

Traditional image editors only offer arbitrary “Quality 80%” sliders without showing the final byte count until after you export.

How In-Browser Target-Size Compression Works

In-browser tools achieve exact target sizes without server round-trips through a combination of the FileReader API, HTML5 Canvas, and Binary Search Quantization:

graph TD UserFile[User Selects Image File] --> MemoryLoad[Loaded into Local Memory via URL.createObjectURL] MemoryLoad --> CanvasRender[Rendered onto In-Memory HTML5 Canvas] CanvasRender --> BinarySearch[Binary Search Quantization Loop: min=0.0, max=1.0] BinarySearch --> BlobCheck{toBlob Output <= Target?} BlobCheck -->|Too Large| LowerQuality[Reduce Max Bound: quality = mid] BlobCheck -->|Too Small| RaiseQuality[Increase Min Bound: quality = mid] BinarySearch --> Converged[Target Met in 6-8 Iterations] Converged --> Download[Instant Zero-Latency Download]

The Binary Search Algorithm in Action:

Initialize Range: minQuality = 0.01, maxQuality = 1.0.
Evaluate Midpoint: currentQuality = (minQuality + maxQuality) / 2.
Generate Blob: canvas.toBlob(blob => ..., 'image/jpeg', currentQuality).
Compare Bytes:
- If blob.size > targetBytes: The quality is too high. Set maxQuality = currentQuality.
- If blob.size <= targetBytes: Record this as the best candidate. Set minQuality = currentQuality.
Terminate: After 6–8 iterations, the algorithm identifies the optimal visual quality that strictly satisfies the size constraint.

Format Efficiency: JPEG vs WebP vs PNG

Metric	JPEG	WebP (Recommended)	PNG
Compression Type	Lossy DCT	Lossy VP8 / Lossless	Lossless DEFLATE
Typical Size at 200KB Quality	Baseline standard	~30% sharper than JPEG	Unsuitable for photos
Alpha Transparency	❌ Not supported	✅ Fully supported	✅ Fully supported
Browser Support	100%	> 97% modern browsers	100%
Best Use Case	Legacy portal uploads	Modern web graphics & photos	Logos, icons, charts

Privacy Advantage: Zero Network Transmission

Uploading scanned driver’s licenses, passports, or tax forms to unknown server-side image compression services presents substantial identity theft risks. Server-side tools frequently write incoming images to disk caches or upload them to third-party cloud buckets.

Because executes strictly in your browser’s local sandbox:

Your files never touch any external server.
No network requests are made during compression.
Closing the tab immediately purges the memory allocation.

Interactive Workbench LIVE

Compress Images to 100KB, 200KB, or 500KB Online (Without Quality Loss)

Open Fullscreen ↗

Select your target size (50KB, 100KB, 200KB, 500KB) and compress photos instantly in memory with zero quality degradation.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

How does in-browser image compression achieve an exact file size like 200KB? ▼

Client-side image tools draw your uploaded image onto an in-memory HTML5 Canvas and run a binary search algorithm across compression quality levels (0.01 to 1.0). In 6 to 8 iterations, the tool converges on the exact quality float that yields a blob size just under your target threshold.

Is my photo uploaded to any server during compression? ▼

No. The entire decoding, resizing, canvas rendering, and re-encoding process happens within your browser's local sandbox memory. No file data or network packets are sent to remote servers.

Should I compress images to WebP or JPEG for the best quality-to-size ratio? ▼

WebP provides approximately 25% to 34% better compression efficiency compared to standard JPEG at equivalent visual quality. For strict portal uploads requiring JPEG, use standard JPEG format; for web performance, select WebP.

Performance | Toolbox Guides & Articles

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

RegEx Tester & Group Matcher

Two Kinds of Regex Engine

How Backtracking Actually Fails

The Three Vulnerable Shapes

1. Nested Quantifiers

2. Overlapping Alternation Under a Quantifier

3. Greedy Dot-Star Next to a Similar Pattern

The Real-World Case

The Rewrites That Fix It

Replace nested quantifiers with a single one

Make alternation branches mutually exclusive

Swap greedy dots for negated character classes

Emulate atomic groups with a lookahead

Bound the input before matching

Flags Worth Knowing

The lastIndex Trap

Detection and Tooling

Step-by-Step: Diagnosing a Pattern with Toolbox

Frequently Asked Questions

Base64 Encoding & Data URI Architecture: The Complete Guide for Web Developers

Base64 Encoder & Data URL Studio

What Is Base64 Encoding?

The 6-Bit Chunking Mathematics

Padding Mechanics (= and ==)

RFC 2397 Data URI Grammar

Anatomical Breakdown

Practical Implementation Examples

Performance Architecture: When to Inline vs When to Link

Character Encoding Safety: Overcoming the btoa Latin1 Bug

The RFC-Compliant Client-Side Solution

Step-by-Step: Converting Files and Assets in Toolbox

Base64 Encoding & Data URI Architecture: The Complete Guide for Web Developers

Frequently Asked Questions

How to Compress Images to 100KB, 200KB, or 500KB Online (Without Quality Loss)

Compress Image to Exact Target Size

Why Exact File Size Compression Matters

How In-Browser Target-Size Compression Works

The Binary Search Algorithm in Action:

Format Efficiency: JPEG vs WebP vs PNG

Privacy Advantage: Zero Network Transmission

Compress Images to 100KB, 200KB, or 500KB Online (Without Quality Loss)

Frequently Asked Questions

The `lastIndex` Trap

Padding Mechanics (`=` and `==`)

Character Encoding Safety: Overcoming the `btoa` Latin1 Bug