Security | Toolbox Guides & Articles

EXIF Metadata and Photo Privacy: What Your Images Reveal and How to Strip It

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

Interactive Workbench LIVE

EXIF Metadata and Photo Privacy: What Your Images Reveal and How to Strip 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

EXIF & Image Metadata Stripper

Load a photo to read every metadata tag it carries, then export a stripped copy. Parsing happens in browser memory, so private photos are never uploaded.

Open EXIF Viewer & Stripper →

The Data You Did Not Mean to Publish

A photograph of a whiteboard, posted to help a colleague, carries the office coordinates to five decimal places. A picture of a pet, shared on a forum, carries a home address in the same field. Neither was visible on screen, and neither was intentional.

Exif — Exchangeable Image File Format, standardised by CIPA and JEITA, currently at version 3.0 — is why. The camera writes a structured metadata block into the file at capture time, and every step afterwards copies it forward unless something explicitly removes it.

What you get from this guide: where the metadata physically lives, which fields matter for privacy, what platforms actually do with them, and how to strip them without recompressing the image.

Where the Metadata Lives

In a JPEG

A JPEG is a sequence of marker segments. Each begins with 0xFF followed by a marker byte:

Marker	Name	Contents
`FFD8`	SOI	Start of image
`FFE0`	APP0	JFIF header
`FFE1`	APP1	Exif block, or XMP packet
`FFE2`	APP2	ICC colour profile
`FFED`	APP13	IPTC / Photoshop resources
`FFDB`	DQT	Quantisation tables
`FFC0`	SOF0	Frame header (dimensions)
`FFDA`	SOS	Start of scan — the compressed pixels
`FFD9`	EOI	End of image

The key structural fact: the Exif block in APP1 is not inside the compressed scan data. It is a separate segment that a parser can skip over. That is what makes lossless stripping possible.

Inside APP1, Exif uses a TIFF-style layout: a header, then Image File Directories (IFDs) of tag entries. IFD0 holds the main image tags, IFD1 the thumbnail, and pointer tags lead to the Exif sub-IFD and the GPS IFD.

The embedded thumbnail deserves its own warning: it is a separate small JPEG stored in the metadata. If you cropped a face or a document out of a photo in some editors, the thumbnail may still show the uncropped original. Stripping metadata removes the thumbnail with it.

In a PNG

PNG is a chunk-based format. Metadata appears as ancillary chunks: eXIf for an Exif block, tEXt, zTXt, and iTXt for text pairs, tIME for modification time, and iCCP for a colour profile. Screenshots and exported graphics commonly carry the software name and timestamps here rather than GPS.

The Fields That Matter

Tag	Typical value	Privacy weight
`GPSLatitude` / `GPSLongitude`	18.5204° N, 73.8567° E	Critical — pinpoints capture location
`GPSAltitude`	13 m	High — narrows to a floor in a building
`GPSDateStamp` / `GPSTimeStamp`	UTC of the GPS fix	High — combined with location, a movement record
`DateTimeOriginal`	2026-08-14 19:42:07	High — establishes presence at a time
`OffsetTimeOriginal`	+05:30	Medium — reveals timezone
`Make` / `Model`	Apple / iPhone 17 Pro	Medium — device fingerprinting
`BodySerialNumber` / `LensSerialNumber`	Serial string	High — links every photo from one device
`Software`	Editing app and version	Low — workflow disclosure
`Artist` / `Copyright`	Photographer name	Medium — often a real legal name
`ImageUniqueID`	Per-image identifier	Medium — correlates re-shared copies
`MakerNote`	Vendor-proprietary blob	Unknown — undocumented; may hold face-detection and more

Two under-appreciated points. Serial numbers correlate: a set of “anonymous” images sharing a BodySerialNumber came from one camera, which is a strong link even without a name. And MakerNote is opaque — it is vendor-specific and undocumented, so its contents cannot be audited. Both argue for removing metadata wholesale rather than editing individual fields.

What Platforms Actually Do

Destination	Typical behaviour
Major social feeds (Instagram, Facebook, X, LinkedIn)	Re-encode uploads; the publicly served copy generally carries no Exif
Messaging apps, sent as a photo	Recompress and generally strip Exif from the delivered image
Messaging apps, sent as a file/document	Original bytes preserved — full Exif travels
Email attachments	Original bytes preserved — full Exif travels
Cloud photo services	Metadata retained by design; shared links may expose location in the UI
Your own website or CDN	Whatever you uploaded is what visitors download

Three conclusions worth internalising:

Platform stripping protects the audience, not you. The platform received the original, coordinates included, and its retention and internal access rules apply to that copy.
The “send as file” path defeats it. Choosing document instead of photo to preserve quality also preserves the entire metadata block — the most common accidental leak among people who believe they are safe because “WhatsApp strips EXIF”.
Self-hosted images are entirely your responsibility. No intermediary re-encodes an image you upload to your own site. Strip at build time.

Stripping Without Quality Loss

The wrong way is to open the image in an editor and re-export it: that decodes and re-encodes the pixels, adding a generation of JPEG loss for no reason. The right way copies the compressed scan data untouched and omits the metadata segments.

// Remove APP1 (Exif/XMP) and APP13 (IPTC) segments from a JPEG, byte-level.
// Scan data (from SOS onward) is copied verbatim: no recompression.
function stripJpegMetadata(bytes) {
 if (bytes[0] !== 0xff || bytes[1] !== 0xd8) throw new Error("Not a JPEG");
 const out = [0xff, 0xd8];
 let i = 2;

 while (i < bytes.length - 1) {
 if (bytes[i] !== 0xff) break;
 const marker = bytes[i + 1];

 // SOS: copy the remainder of the file unchanged and finish.
 if (marker === 0xda) { out.push(...bytes.slice(i)); break; }

 const len = (bytes[i + 2] << 8) | bytes[i + 3]; // includes the 2 length bytes
 const drop = marker === 0xe1 || marker === 0xed; // APP1 (Exif/XMP), APP13 (IPTC)
 if (!drop) out.push(...bytes.slice(i, i + 2 + len));
 i += 2 + len;
 }
 return new Uint8Array(out);
}

Note what this deliberately keeps: APP2, the ICC colour profile. Dropping it is not a privacy win and can visibly shift colours on wide-gamut images. Strip identity, keep rendering.

Command-line equivalents:

# exiftool: remove all metadata, no pixel re-encode
exiftool -all= photo.jpg

# Remove only location, keep exposure data for a photography portfolio
exiftool -gps:all= -xmp:geotag= photo.jpg

# Verify nothing remains
exiftool -a -G1 -s photo.jpg

The verification step is not optional. Some tools clear IFD0 but leave the GPS IFD, or clear Exif but leave an XMP packet holding the same coordinates in a different syntax.

A Practical Policy

Context	Recommended handling
Personal photos to social media	Strip all metadata before upload
Photos of your home, children, or workplace	Strip all metadata; also check the embedded thumbnail is gone
Photography portfolio	Keep exposure and lens data, remove GPS and serial numbers
Journalism or activism	Strip all metadata; assume the file will be analysed adversarially
Product images on your own site	Strip in the build pipeline, not manually
Legal or forensic evidence	Do not strip — metadata is part of the evidentiary record; preserve the original and work on copies

That last row is the exception that matters: for evidence, provenance metadata is the point, and stripping it destroys the file’s value. Everywhere else, removal is the default.

Step-by-Step: Auditing and Stripping with Toolbox

Open the tool: visit the and load a photo straight from your camera roll.
Read the GPS block first. If coordinates are present, paste them into a map to see precisely what the file discloses — this is the step that changes people’s habits.
Check the device fields: Make, Model, and any serial number, which are the tags that correlate separate images to one camera.
Strip and export. The stripped copy retains identical pixels because the compressed scan data is copied rather than re-encoded.
Re-load the stripped file in the same tool to confirm the GPS IFD, XMP packet, and embedded thumbnail are all gone — not just the main IFD.
Then compress if needed. If the image is also going to be resized or size-limited, do that after stripping using the .

Outcome: images you can publish without disclosing where they were taken, on what device, or when — with visual quality byte-identical to the original and a verification pass proving the metadata actually left.

Related guides: · ·

FAQ

Frequently Asked Questions

Does uploading a photo to Instagram or WhatsApp remove its GPS data? ▼

Major platforms re-encode uploads and generally discard EXIF from the copy they serve publicly, so a downloaded post rarely carries coordinates. But the platform still received the original including location, and sending an image as a file or document attachment rather than as a photo commonly preserves the original bytes and the full EXIF block. Strip before sharing rather than relying on the platform.

Does removing EXIF metadata reduce image quality? ▼

No, when done correctly. EXIF sits in an APP1 marker segment alongside the compressed image data, not inside it, so the segment can be dropped while the scan data is copied through untouched — a lossless operation. Quality only suffers if a tool decodes and re-encodes the image to remove metadata.

What is the difference between EXIF, XMP, IPTC, and ICC data? ▼

EXIF, standardised by CIPA and JEITA and now at version 3.0, holds camera-generated technical data including exposure, lens, timestamps, and a GPS sub-directory. XMP is Adobe's XML metadata written by editing software. IPTC carries editorial fields such as caption, creator, and copyright. ICC is a colour profile — not privacy data, but dropping it can visibly shift colours in wide-gamut images.

Can EXIF be removed from a photo I already published? ▼

Only from copies you still control. Every downloaded copy keeps what it was published with, and caches, archives, mirrors, and messaging backups may hold it indefinitely. Replace the published file with a stripped version to stop new exposure, and treat the earlier disclosure as permanent — especially where the coordinates identify a home or routine location.

How TOTP 2FA Codes Work: RFC 6238 Math, Base32 Secrets, and Clock Drift

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

Interactive Workbench LIVE

How TOTP 2FA Codes Work: RFC 6238 Math, Base32 Secrets, and Clock Drift

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

TOTP 2FA Authenticator Simulator

Paste a Base32 secret and watch live 6-digit codes rotate on a 30-second timer. Secrets are decoded in browser memory and never transmitted.

Open TOTP Code Simulator →

What TOTP Actually Is

Time-based One-Time Password (TOTP) is defined in RFC 6238. It is not a new algorithm — it is a thin wrapper around HMAC-based One-Time Password (HOTP), specified in RFC 4226. HOTP derives a code from a shared secret and a moving counter. TOTP simply says: use the clock as the counter.

That one substitution is what makes authenticator apps work offline. There is no request to Google, Authy, or your identity provider when a code appears. The phone holds the secret, reads its own clock, and computes the answer. The server does the identical computation and compares.

What you get from this guide: the exact formula, the truncation step almost every explanation skips, the enrolment URI format, and the three failure modes that generate support tickets.

The RFC 6238 Formula, Step by Step

Step 1: Derive the time counter

T = floor((Current Unix Time - T0) / X)

Symbol	Meaning	Default
`Current Unix Time`	Seconds since 1970-01-01T00:00:00Z, UTC	—
`T0`	Epoch offset from which counting starts	`0`
`X`	Time step in seconds	`30`

At Unix time 1789000000, with defaults, T = floor(1789000000 / 30) = 59633333.

Step 2: Compute the HMAC

T is encoded as an 8-byte big-endian unsigned integer and passed as the message to HMAC, keyed with the raw secret:

HS = HMAC-SHA1(K, T) // 20-byte digest

The default hash is SHA-1. RFC 6238 explicitly permits HMAC-SHA256 and HMAC-SHA512. Using SHA-1 here is not the weakness people assume — HMAC’s security relies on the pseudorandomness of the compression function, not on collision resistance, so the known SHA-1 collision attacks do not translate into TOTP forgery. Read the underlying construction in the .

Step 3: Dynamic truncation

This is the step most tutorials omit, and the reason a naive implementation produces codes the server rejects.

offset = HS[19] & 0x0F // low 4 bits of the last byte
P = HS[offset..offset+3] // 4 consecutive bytes
binCode = P & 0x7FFFFFFF // clear the most significant bit

Masking the high bit removes any signed-integer ambiguity across language implementations. The result is a 31-bit integer.

Step 4: Reduce to digits

Code = binCode mod 10^Digits

With Digits = 6, binCode = 1284755224 yields 755224 — the canonical RFC 4226 test vector. Codes are zero-padded to the full width: 000042 is a valid code, 42 is not.

Reference implementation

// Browser-native TOTP with Web Crypto. rawKey = Base32-decoded secret bytes.
async function totp(rawKey, { digits = 6, step = 30, algo = "SHA-1" } = {}) {
 const counter = Math.floor(Date.now() / 1000 / step);

 // 8-byte big-endian counter
 const msg = new DataView(new ArrayBuffer(8));
 msg.setUint32(0, Math.floor(counter / 2 ** 32));
 msg.setUint32(4, counter >>> 0);

 const key = await crypto.subtle.importKey(
 "raw", rawKey, { name: "HMAC", hash: algo }, false, ["sign"]
 );
 const hs = new Uint8Array(await crypto.subtle.sign("HMAC", key, msg.buffer));

 const offset = hs[hs.length - 1] & 0x0f;
 const bin =
 ((hs[offset] & 0x7f) << 24) |
 (hs[offset + 1] << 16) |
 (hs[offset + 2] << 8) |
 hs[offset + 3];

 return String(bin % 10 ** digits).padStart(digits, "0");
}

Base32 Secrets: Why Not Base64?

The shared secret is transported as Base32 (RFC 4648, the same document that defines Base64 — see the for the shared 5-bit and 6-bit chunking mechanics).

Base32 is the deliberate choice for three reasons:

Case-insensitive alphabet (A-Z and 2-7) — a user can retype it from a printed backup without shift-key errors.
No visually ambiguous characters — 0, 1, and 8 are excluded, so O/0 and l/1 confusion disappears.
Safe in URIs and QR codes without percent-encoding.

Practical detail that breaks implementations: Base32 padding (=) is optional in authenticator secrets, and most apps strip whitespace and lowercase before decoding. A 160-bit secret encodes to 32 Base32 characters. RFC 4226 requires a minimum of 128 bits and recommends 160 bits.

The Enrolment QR Code: `otpauth://` URI

The QR code you scan is a plain text URI in the Key Uri Format:

otpauth://totp/Acme%20Inc:alice@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Acme%20Inc&algorithm=SHA1&digits=6&period=30

Parameter	Purpose	Practical note
`secret`	Base32 shared key	Required. Everything else has a default.
`issuer`	Service name shown in the app	Set it in both the label prefix and the query parameter — older apps read only one.
`algorithm`	`SHA1`, `SHA256`, `SHA512`	Widely ignored by popular apps, which assume SHA-1.
`digits`	`6` or `8`	Also frequently ignored.
`period`	Time step in seconds	Also frequently ignored.

Design consequence: if your server issues algorithm=SHA256&digits=8 and your users authenticate with an app that silently assumes SHA-1 and 6 digits, every code fails and the failure is indistinguishable from a wrong password. Unless you control the client, stay on the SHA-1 / 6-digit / 30-second defaults.

Clock Drift, Validation Windows, and Replay

TOTP has no synchronisation channel. The protocol’s entire tolerance mechanism is the server checking neighbouring time steps.

Server window	Effective validity	Trade-off
`T` only	0-30 s	Rejects codes typed slowly; poor UX
`T-1, T, T+1`	Up to 90 s	Common default; absorbs drift and typing delay
`T-2 … T+2`	Up to 150 s	Use only with strict rate limiting

Three rules that separate a correct deployment from a fragile one:

Run NTP on the server. Client drift is the user’s problem; server drift breaks every user at once.
Burn the code after use. RFC 6238 § 5.2 is explicit: accept each code once per user per time step. Without this, a code intercepted at second 1 stays replayable for the rest of the window.
Rate-limit attempts. A 6-digit code is 1,000,000 possibilities. At an unlimited request rate, an attacker inside a 90-second window has real odds. Cap at roughly 5 failures, then lock or back off exponentially.

Where TOTP Fits in 2026

Factor	SMS OTP	TOTP (RFC 6238)	FIDO2 / Passkey
Works offline	❌	✅	✅
Resists SIM swap	❌	✅	✅
Resists real-time phishing	❌	❌	✅ (origin-bound)
Server holds a reusable secret	✅ (risk)	✅ (risk)	❌ (public key only)
Recovery burden	Low	Medium (backup codes)	Medium (multi-device sync)

TOTP’s structural weakness is the shared secret at rest. The server must store the key in a form it can compute with, so a database breach exposes every enrolled seed unless the seeds are encrypted with a key held outside the database. Store them encrypted, and treat the enrolment QR code as a credential — a screenshot in a chat thread is a bypassed second factor.

Step-by-Step: Testing TOTP Codes with Toolbox

Open the tool: visit the .
Paste the Base32 secret produced by your enrolment endpoint (spacing and case are normalised for you).
Set algorithm, digits, and period to match your server configuration — this is where SHA-256 or 8-digit mismatches surface immediately.
Compare against your backend: call your verification endpoint with the displayed code while the countdown ring is above roughly 5 seconds, so a step boundary does not confuse the result.
Reproduce drift deliberately: verify a code just as the ring empties to confirm your server actually accepts T-1 and does not silently reject late submissions.

Outcome: you can prove whether a failing 2FA flow is a secret-encoding bug, an algorithm mismatch, or a clock/window problem — without installing a mobile app or exposing the seed to a third-party service.

Related guides: · ·

FAQ

Frequently Asked Questions

How does an authenticator app generate a 6-digit code without internet access? ▼

The app stores a shared secret exchanged once during enrolment (usually via a QR code). Every 30 seconds it computes HMAC-SHA1 over the current time step (Unix time divided by 30), truncates the 20-byte digest to a 31-bit integer, and takes that value modulo 1,000,000 for 6 digits. Both phone and server hold the same secret and read the same clock, so they derive the same code with no network round trip.

Why do TOTP codes change every 30 seconds? ▼

RFC 6238 defines a time step X (default 30 seconds) and computes T = floor((current Unix time - T0) / X), with T0 normally 0. Each time T increments, the HMAC input changes and a new code appears. Thirty seconds balances usability against how long a stolen code stays valid.

What happens if my phone's clock is wrong? ▼

TOTP has no synchronisation protocol, so a device off by more than one time step produces codes the server rejects. Most servers accept the previous and next step (roughly a 90-second window) to absorb drift and typing delay. Persistent failures are fixed by enabling automatic network time on the device, not by retyping codes.

Is TOTP still secure in 2026, or should I move to passkeys? ▼

TOTP is far stronger than SMS one-time passwords and satisfies most compliance baselines, but it is phishable: a real-time phishing proxy can relay the digits inside the validity window, and the shared seed can leak from a breached database or a screenshotted QR code. Where phishing is in scope, FIDO2 or WebAuthn passkeys are stronger because the signed challenge is bound to the origin.

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.

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

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

Interactive Workbench LIVE

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

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

RSA & ECC Keypair Generator

Generate RSA keypairs in PKCS#8 and SPKI PEM using the browser's own Web Crypto implementation. Private key material never leaves local memory.

Open Air-Gapped Keypair Generator →

Two Ways to Build a Trapdoor

Asymmetric cryptography needs a function that is easy forwards and infeasible backwards. RSA and ECC pick different hard problems:

RSA (RFC 8017) relies on the difficulty of factoring a modulus n = p × q into its two large primes. Public key: (n, e). Private key: (n, d) plus the CRT parameters that make decryption fast.
ECC relies on the elliptic curve discrete logarithm problem: given points G and Q = kG on a curve, recover the scalar k. Public key: the point Q. Private key: the scalar k.

The consequence is not academic. The best classical attack on RSA — the general number field sieve — runs in sub-exponential time, so RSA key sizes must grow steeply to keep pace with hardware. The best generic attack on a well-chosen curve is Pollard’s rho at roughly the square root of the group order, so ECC key sizes grow linearly with security. That single difference explains the entire comparison table below.

What you get from this guide: a defensible key-size choice, the ability to read any PEM file you are handed, and a clear view of what post-quantum migration does and does not demand of you today.

Security Strength: The Only Fair Comparison

Key length is meaningless across algorithm families. The comparable unit is security strength in bits, expressed as the equivalent symmetric key.

Security strength	RSA modulus	Elliptic curve	Symmetric equivalent
112 bits	RSA-2048	P-224	3TDEA (legacy)
128 bits	RSA-3072	P-256 (secp256r1)	AES-128
192 bits	RSA-7680	P-384 (secp384r1)	AES-192
256 bits	RSA-15360	P-521 (secp521r1)	AES-256

Two practical readings of this table:

RSA-2048 is the current floor, not a target. It sits at 112-bit strength, which NIST’s transition guidance schedules for phase-out by 2030 and disallowance by 2035. New long-lived keys should be RSA-3072 or an elliptic curve.
RSA-4096 is not the obvious upgrade. It buys roughly 140 bits of strength for four to eight times the signing cost of RSA-3072. P-256 reaches 128 bits with a 32-byte private scalar and signs an order of magnitude faster.

Performance shape

Operation	RSA-2048	ECDSA P-256
Key generation	Slow (prime search)	Fast (one scalar multiply)
Sign / decrypt	Slow (private exponent)	Fast
Verify / encrypt	Very fast (small `e = 65537`)	Moderate
Public key size	~294 bytes (SPKI DER)	~91 bytes (SPKI DER)
Signature size	256 bytes	~64-72 bytes (DER)

RSA’s asymmetry — cheap verification, expensive signing — is why it survived so long in TLS server certificates, where a server signs once per handshake but clients verify constantly. It is also why RSA keygen in a browser can take a visible second at 4096 bits while an ECDSA keypair appears instantly.

Reading a PEM File

A PEM file is Base64-encoded DER (Distinguished Encoding Rules), the canonical binary serialisation of an ASN.1 structure, wrapped in armour lines. The header tells you exactly which structure is inside.

Header line	Structure	Contains
`-----BEGIN PUBLIC KEY-----`	SubjectPublicKeyInfo (RFC 5280)	Algorithm identifier + public key bits
`-----BEGIN PRIVATE KEY-----`	PKCS#8 PrivateKeyInfo (RFC 5958)	Algorithm identifier + private key
`-----BEGIN ENCRYPTED PRIVATE KEY-----`	PKCS#8 EncryptedPrivateKeyInfo	Passphrase-wrapped private key
`-----BEGIN RSA PRIVATE KEY-----`	PKCS#1 RSAPrivateKey (RFC 8017)	RSA parameters only, no algorithm identifier
`-----BEGIN EC PRIVATE KEY-----`	SEC1 ECPrivateKey (RFC 5915)	Curve parameters + scalar
`-----BEGIN CERTIFICATE-----`	X.509 Certificate	A signed public key — see the

The modern, algorithm-agnostic pair is PKCS#8 for private and SPKI for public; those are the two formats the Web Crypto API exports. The older PKCS#1 and SEC1 forms are algorithm-specific, which is why tooling has converged on PKCS#8.

Generating a keypair with Web Crypto

// RSA-3072 signing keypair, exported as PKCS#8 + SPKI PEM.
const { publicKey, privateKey } = await crypto.subtle.generateKey(
 {
 name: "RSASSA-PKCS1-v1_5", // or "RSA-PSS" / "RSA-OAEP" for encryption
 modulusLength: 3072,
 publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // 65537
 hash: "SHA-256",
 },
 true, // extractable
 ["sign", "verify"]
);

const toPem = (der, label) => {
 const b64 = btoa(String.fromCharCode(...new Uint8Array(der)));
 return `-----BEGIN ${label}-----\n${b64.match(/.{1,64}/g).join("\n")}\n-----END ${label}-----`;
};

const privatePem = toPem(await crypto.subtle.exportKey("pkcs8", privateKey), "PRIVATE KEY");
const publicPem = toPem(await crypto.subtle.exportKey("spki", publicKey), "PUBLIC KEY");

Three details that trip people up:

publicExponent is 65537 (0x010001). It is a Fermat prime with only two set bits, making verification fast; smaller exponents such as 3 have historically enabled padding attacks in badly implemented verifiers.
Base64 lines wrap at 64 characters. Some strict parsers reject unwrapped single-line PEM.
extractable: true is required to export at all. Set it to false for keys that should stay inside the browser’s key store.

The SSH format gap

A -----BEGIN PUBLIC KEY----- block cannot be pasted into ~/.ssh/authorized_keys. OpenSSH uses its own wire encoding — an algorithm name, then length-prefixed fields, Base64-encoded onto one line:

# SPKI PEM -> OpenSSH public key line
ssh-keygen -i -m PKCS8 -f public.pem

# PKCS#8 private key -> OpenSSH private key file
ssh-keygen -p -m RFC4716 -f id_rsa

Also worth knowing: OpenSSH’s recommended key type today is Ed25519, and the Web Crypto generateKey algorithms for RSA and ECDSA do not produce it. Generate Ed25519 keys with ssh-keygen -t ed25519.

Choosing an Algorithm in 2026

Use case	Recommendation	Reasoning
New TLS server certificate	ECDSA P-256, RSA-2048/3072 as fallback	Smaller handshake; universally supported by browsers
JWT signing	ES256 (ECDSA P-256) or RS256	ES256 gives shorter tokens; see the
SSH user key	Ed25519 via `ssh-keygen`	Small, fast, no curve-parameter footguns
Legacy enterprise PKI	RSA-3072	Broadest hardware and appliance support
Encrypting data directly	Neither — use hybrid	Encrypt with , wrap the AES key with RSA-OAEP or ECDH

The RSA-OAEP Size Limit and Why Hybrid Encryption Exists

RSA does not encrypt streams. It encrypts one integer smaller than the modulus. With OAEP padding (RFC 8017) the usable plaintext is:

max plaintext bytes = k - 2 * hLen - 2

k = modulus size in bytes
hLen = hash output size in bytes

Key size	`k`	OAEP hash	Maximum plaintext
2048-bit	256 bytes	SHA-1 (20)	214 bytes
2048-bit	256 bytes	SHA-256 (32)	190 bytes
3072-bit	384 bytes	SHA-256 (32)	318 bytes
4096-bit	512 bytes	SHA-256 (32)	446 bytes

190 bytes will not hold a document, a database row, or a session payload — which is why real systems use hybrid encryption:

Generate a random AES-256 content key.
Encrypt the payload with AES-256-GCM — fast, streaming, authenticated.
Encrypt only the 32-byte AES key with RSA-OAEP (or derive it with ECDH).
Ship the wrapped key alongside the ciphertext.

That is the structure inside TLS, JWE, S/MIME, and PGP: the asymmetric half transports a key, the symmetric half does the work. See the for the symmetric side.

Signature padding: PSS or PKCS#1 v1.5?

Scheme	Status	Use when
RSA-PSS	Recommended (RFC 8017)	Any new system — randomised padding with a formal security proof
RSASSA-PKCS1-v1_5	Legacy but ubiquitous	Interoperating with existing TLS certificates and JWT `RS256`
Raw RSA, no padding	Never	Textbook RSA is deterministic and trivially malleable

Never encrypt bulk data with RSA. RSA-OAEP can encrypt at most a few hundred bytes for a given modulus. The correct pattern is hybrid encryption: generate a random symmetric key, encrypt the payload with AES-GCM, and encrypt only that symmetric key with the recipient’s public key.

Where post-quantum stands

NIST finalised three post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. FIPS 206 (FN-DSA) remains a draft as of 2026. NIST’s transition schedule phases out 112-bit-strength classical algorithms by 2030 and disallows them from 2035; NSA’s CNSA 2.0 sets 2030 for national security systems.

Shor’s algorithm on a sufficiently large quantum computer would factor RSA moduli efficiently, breaking RSA at every key size, and would solve elliptic curve discrete logarithms too. No such machine exists today, but ciphertext captured now can be stored for later decryption — the harvest now, decrypt later problem. The deployed transition path is hybrid: combine a classical key exchange with ML-KEM so the session survives if either component fails.

For an application team, the actionable version is short: do not rewrite your PKI this quarter, but stop hardcoding algorithm names, keep certificate lifetimes short so rotation is routine, and inventory where long-lived signatures and long-lived encrypted archives live — those are the assets exposed to “harvest now, decrypt later”.

Step-by-Step: Generating and Inspecting Keys with Toolbox

Open the tool: visit the .
Pick a modulus size: 2048 for legacy interoperability, 3072 for a 128-bit strength target, 4096 only when a policy demands it.
Generate: the browser’s Web Crypto implementation performs the prime search locally; nothing is sent over the network.
Copy both PEM blocks: the PKCS#8 private key and the SPKI public key. Store the private key in a secret manager immediately — a key that has been in a clipboard buffer and then an email is not a secret.
Verify the pair matches before deploying:

openssl rsa -in private.pem -pubout | diff - public.pem && echo "pair OK"
openssl rsa -in private.pem -noout -text | head -2 # confirms modulus size

Outcome: a correctly encoded, verified keypair for local development, signing tests, or PKI experiments — generated without pasting a private key into a remote web service.

Related guides: · ·

FAQ

Frequently Asked Questions

Is a 256-bit ECC key really as strong as a 3072-bit RSA key? ▼

Against classical attacks, yes. Strength is measured in equivalent symmetric bits: RSA-2048 is about 112 bits, while RSA-3072 and NIST P-256 are both about 128 bits. RSA keys must grow much faster because the general number field sieve is sub-exponential, whereas the best generic attack on elliptic curve discrete logarithms takes square-root time in the group order.

What is the difference between PKCS#8 and SPKI PEM files? ▼

PKCS#8 (RFC 5208 / RFC 5958) is the standard private-key container and starts with BEGIN PRIVATE KEY. SPKI, or SubjectPublicKeyInfo (RFC 5280), is the standard public-key container and starts with BEGIN PUBLIC KEY. Both are Base64-wrapped DER ASN.1. The older PKCS#1 form, BEGIN RSA PRIVATE KEY, carries only RSA parameters with no algorithm identifier.

Can I paste a generated PEM public key into authorized_keys for SSH? ▼

No. OpenSSH uses its own one-line format beginning with ssh-rsa, ecdsa-sha2-nistp256, or ssh-ed25519 followed by Base64 of a length-prefixed structure. Convert a SPKI PEM with ssh-keygen -i -m PKCS8 -f public.pem. Note that Ed25519, OpenSSH's preferred modern type, is not produced by the Web Crypto RSA or ECDSA algorithms.

Should I generate post-quantum keys instead of RSA or ECC today? ▼

For most TLS, SSH, and signing work RSA and ECC remain the interoperable choice in 2026. NIST finalised ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024, while FN-DSA (FIPS 206) is still draft, and NIST schedules 112-bit-strength algorithms for phase-out by 2030 and disallowance by 2035. Prioritise crypto-agility: configurable algorithms, short certificate lifetimes, and an inventory of long-lived secrets.

AES-256-GCM Authenticated Encryption: How to Secure Data in the Browser

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

Free In-Browser Tool TOOLBOX UTILITY

AES Encryption & Decryption Utility

Encrypt and decrypt confidential text using AES-GCM or AES-CBC directly in your browser with hardware-accelerated Web Crypto API.

Open AES-256 Web Crypto Tool →

What Is AES and How Does Modern Symmetric Cryptography Work?

The Advanced Encryption Standard (AES), standardized by the US National Institute of Standards and Technology (NIST FIPS 197), is the gold standard symmetric block cipher protecting modern internet communications (TLS 1.3), database storage encryption, disk volumes (BitLocker, FileVault), and zero-knowledge cloud applications.

As a symmetric cipher, AES uses the same secret key for both encryption and decryption. It operates on fixed 128-bit (16-byte) blocks of data through multiple rounds of substitution and permutation operations (SubBytes, ShiftRows, MixColumns, and AddRoundKey):

AES-128: 10 rounds (128-bit key)
AES-192: 12 rounds (192-bit key)
AES-256: 14 rounds (256-bit key)

AES-256 provides a theoretical keyspace of $2^{256} \approx 1.15 \times 10^{77}$ combinations, rendering brute-force attacks physically impossible with classical computers.

The Critical Role of Block Cipher Modes

A raw block cipher can only transform a single 16-byte block of plaintext. To encrypt arbitrary-length messages or streams, a mode of operation must be employed. The choice of mode dictates whether your encryption is robust or fatally flawed.

1. Electronic Codebook (ECB) — Fatally Insecure

In ECB mode, every 16-byte block is encrypted independently with the key. Identical plaintext blocks produce identical ciphertext blocks.

⚠️ The ECB Penguin Problem: Encrypting a bitmap image with ECB preserves the visual contours and structure of the image in the ciphertext. Never use ECB in production.

2. Cipher Block Chaining (CBC) — Legacy Malleability

In CBC mode, each plaintext block is XORed with the preceding ciphertext block before encryption.

Requires an Initialization Vector (IV) for the first block.
Requires padding (PKCS#7) to round the message up to an exact multiple of 16 bytes.
Vulnerability: CBC only provides confidentiality, not integrity. Without a secondary MAC (Message Authentication Code), CBC is susceptible to bit-flipping attacks and padding oracle attacks (such as POODLE).

3. Galois/Counter Mode (GCM) — The Gold Standard AEAD

AES-GCM combines counter-mode encryption with universal hashing over a Galois field $\text{GF}(2^{128})$.

AEAD (Authenticated Encryption with Associated Data): Simultaneously encrypts the payload and computes a 128-bit authentication tag (GMAC).
Tamper Resistance: If an attacker modifies even a single bit of the ciphertext or IV, decryption fails with an authentication error before any decrypted data is returned.
No Padding Needed: Operates as a stream cipher over counter increments; plaintexts of arbitrary byte lengths are encrypted without padding.
High Performance: Allows full pipelining and hardware acceleration via CPU instructions like Intel AES-NI and ARMv8 Cryptography.

The Nonce/IV Mandate: Why 96-Bit IV Uniqueness Is Absolute

In AES-GCM, the Initialization Vector (IV), often referred to as a nonce (number used once), initializes the counter function.

Counter Block 1 = IV (96 bits) || 0x00000001 (32 bits)
Counter Block 2 = IV (96 bits) || 0x00000002 (32 bits)

The Catastrophic “Two-Time Pad” Failure

If the same key and IV pair is reused across two different plaintexts ($P_1$ and $P_2$):

$$C_1 = P_1 \oplus \text{Keystream}$$

$$C_2 = P_2 \oplus \text{Keystream}$$

$$C_1 \oplus C_2 = P_1 \oplus P_2$$

An eavesdropper XORs the two ciphertexts to cancel out the keystream entirely, revealing the direct XOR of the plaintexts. Furthermore, the Galois hash key $H$ can be recovered mathematically, allowing the attacker to forge valid authentication tags.

Standard Operating Rules for IVs:

Never reuse an IV with the same key.
IVs are not secret: The IV is prepended in the clear to the ciphertext (e.g. [12-byte IV] + [Ciphertext] + [16-byte Tag]).
Always use CSPRNG: In web applications, generate IVs strictly with window.crypto.getRandomValues(new Uint8Array(12)).

Architectural Comparison of AES Modes

Security & Performance Dimension	AES-GCM (Recommended)	AES-CBC	AES-ECB (Broken)
Cipher Classification	AEAD (Authenticated)	Confidentiality Only	Raw Block Cipher
Authentication / Integrity	✅ Built-in 128-bit GMAC	❌ None (Requires HMAC)	❌ None
Padding Oracle Vulnerability	Immune (No padding used)	Vulnerable to padding oracles	Not applicable
Bit-Flipping Malleability	Detected & rejected immediately	Vulnerable without HMAC	Vulnerable
Parallel Processing	Fully parallelizable (SIMD)	Sequential encryption only	Parallelizable
Standard IV Length	96 bits (12 bytes)	128 bits (16 bytes)	No IV used
Standard Adoption	TLS 1.3, IPsec, WebCrypto, SSH	Legacy TLS, OpenVPN	Strictly prohibited

Client-Side Web Crypto API Implementation

Modern web browsers feature hardware-accelerated, cryptographically secure primitives via the W3C Web Cryptography API (crypto.subtle).

Here is the standard implementation for AES-GCM encryption and decryption:

// 1. Generate a Cryptographically Secure 256-bit Key
async function generateAesKey() {
 return await window.crypto.subtle.generateKey(
 { name: "AES-GCM", length: 256 },
 true,
 ["encrypt", "decrypt"]
 );
}

// 2. Encrypt UTF-8 Plaintext with AES-GCM
async function encryptAesGcm(plaintext, key) {
 const ec = new TextEncoder();
 // Generate a fresh, unique 96-bit (12-byte) IV for every encryption operation
 const iv = window.crypto.getRandomValues(new Uint8Array(12));

 const ciphertextWithTag = await window.crypto.subtle.encrypt(
 { name: "AES-GCM", iv: iv, tagLength: 128 },
 key,
 ec.encode(plaintext)
 );

 // Pack IV + Ciphertext + Tag into a single buffer for transmission
 const combined = new Uint8Array(iv.length + ciphertextWithTag.byteLength);
 combined.set(iv, 0);
 combined.set(new Uint8Array(ciphertextWithTag), iv.length);

 // Return as Base64 string
 return btoa(String.fromCharCode(...combined));
}

// 3. Decrypt and Verify Integrity
async function decryptAesGcm(base64Payload, key) {
 const binaryString = atob(base64Payload);
 const combined = Uint8Array.from(binaryString, c => c.charCodeAt(0));

 // Extract 12-byte IV and Ciphertext
 const iv = combined.slice(0, 12);
 const data = combined.slice(12);

 // Decryption throws an error if authentication tag does not match
 const decrypted = await window.crypto.subtle.decrypt(
 { name: "AES-GCM", iv: iv, tagLength: 128 },
 key,
 data
 );

 return new TextDecoder().decode(decrypted);
}

Step-by-Step: Encrypting Data in Toolbox

Open the Tool: Visit the .
Select Mode: Choose AES-GCM (Authenticated) for state-of-the-art security, or AES-CBC for legacy compatibility.
Set Key Size: Choose 256-bit for maximum cryptographic resilience.
Enter Plaintext & Secret Key: Input your text and provide a passphrase, or click Generate Secure Key to obtain a high-entropy hex key.
Client-Side Execution: The tool uses your browser’s hardware-accelerated crypto.subtle engine. Zero plaintext or keys ever touch any remote server.
Copy Encrypted Ciphertext: Retrieve the resulting Base64-encoded bundle containing the IV, ciphertext, and authentication tag.

Interactive Workbench LIVE

AES-256-GCM Authenticated Encryption: How to Secure Data in the Browser

Open Fullscreen ↗

Encrypt and decrypt confidential text using AES-GCM or AES-CBC directly in your browser with hardware-accelerated Web Crypto API.

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 is AES-GCM considered superior to AES-CBC for web applications? ▼

AES-GCM is an Authenticated Encryption with Associated Data (AEAD) cipher mode. Unlike AES-CBC, which only provides confidentiality and is vulnerable to padding oracle attacks unless paired with a separate HMAC, AES-GCM simultaneously provides confidentiality and cryptographic integrity through a 128-bit authentication tag (GMAC). Any tampering with the ciphertext causes decryption to fail immediately.

Why is reusing an Initialization Vector (IV) catastrophic in AES-GCM? ▼

In Galois/Counter Mode, the keystream is generated by encrypting incrementing counter blocks derived from the IV and key. If the same (Key, IV) pair is used to encrypt two different plaintexts, an attacker can XOR the ciphertexts to eliminate the keystream and uncover the XOR of the plaintexts, completely destroying confidentiality and enabling forgery of the authentication tag.

What is the recommended IV length for AES-GCM? ▼

The NIST SP 800-38D specification strongly recommends an Initialization Vector length of exactly 96 bits (12 bytes). A 96-bit IV is used directly as the initial counter block without undergoing additional GHASH processing, maximizing both performance and cryptographic security.

Is client-side browser encryption secure against server eavesdropping? ▼

Yes. When encryption executes inside the browser using the W3C Web Crypto API (crypto.subtle), plaintext data is transformed into ciphertext in local machine memory before any network transmission occurs. As long as keys are derived and held client-side and the serving domain has strict HTTPS and Content Security Policy (CSP), zero-knowledge confidentiality is preserved.

How to Format and Validate JSON in Your Browser (Safely)

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

Free In-Browser Tool TOOLBOX UTILITY

JSON Formatter & Validator

Format, validate, and inspect JSON payloads with line-numbered error diagnostics and zero server tracking.

Open JSON Formatter with Sample →

Why JSON Formatting & Validation Is Critical

JavaScript Object Notation (JSON) is the undisputed standard data interchange format across modern web APIs, microservices, database storage (PostgreSQL jsonb), and cloud configuration files.

However, minified API responses or hand-edited JSON files frequently cause catastrophic runtime crashes due to minute syntax infractions. When developers paste sensitive production payloads—such as authorization tokens, customer records, or API credentials—into random third-party formatting websites, they risk exposing confidential data to server logs, analytics trackers, and third-party scraping.

Using a 100% client-side JSON formatter guarantees that your data never leaves your workstation’s RAM.

Strict RFC 8259 Syntax Rules You Must Follow

JSON syntax is governed by the IETF RFC 8259 standard. Unlike JavaScript object literals, JSON enforces a rigid subset of rules:

Keys Must Be Double-Quoted: Single quotes ('id': 1) or unquoted keys (id: 1) will throw a syntax error. Only "id": 1 is valid.
Strings Must Use Double Quotes: Single quotes are strictly forbidden for string values.
No Trailing Commas: Trailing commas after the final element in an array [1, 2, 3,] or object {"a": 1,} violate the standard grammar.
Permitted Primitive Types Only:
- string (UTF-8, enclosed in double quotes)
- number (integer or floating point; NaN and Infinity are forbidden)
- boolean (true or false)
- null
- object ({ ... })
- array ([ ... ])
No Comments: Standard JSON does not support // single-line comments or /* */ block comments.

Common JSON Errors & How to Fix Them

Error Message	Root Cause	Solution
`Unexpected token ' in JSON at position X`	Using single quotes instead of double quotes	Replace all `'` with `"` around keys and strings
`Unexpected token , in JSON at position X`	Trailing comma after final key or array item	Remove the superfluous comma before `}` or `]`
`Unexpected token } in JSON at position X`	Missing value after colon or unclosed quotation	Ensure every key has a corresponding value
`Unterminated string in JSON at position X`	Unescaped line break or missing closing quote	Escape special characters (`\n`, `\t`, `\"`)

Architecture Comparison: Client-Side vs Server-Side Formatters

Security & Performance Dimension	In-Browser Client-Side (Toolbox)	Traditional Server-Side Tools
Data Transmission	0 KB (Never leaves browser RAM)	Transmitted via HTTP POST to third-party server
Server Logging Risk	Zero Risk (No server receives data)	High (Stored in Nginx/Apache access & error logs)
Execution Latency	Instantaneous (< 5ms via V8)	150ms – 800ms (Network round-trip latency)
Offline Availability	Fully functional offline	Fails without active internet connection
Compliance (GDPR / HIPAA)	100% Compliant	Potential compliance violation

Step-by-Step: Formatting JSON in Toolbox

Open the Tool: Navigate to the .
Paste Your Payload: Insert your raw or minified JSON payload into the input editor.
Instant Validation: The editor immediately executes JSON.parse(). If valid, it indents the structure with your choice of 2 spaces, 4 spaces, or tabs.
Debug Syntax Errors: If the payload contains errors, the diagnostic gutter highlights the exact line and column where parsing halted.
Copy or Minify: Click Copy Formatted to transfer the clean output to your clipboard, or click Minify to strip whitespace for production payloads.

Interactive Workbench LIVE

Format and Validate JSON in Your Browser (Safely)

Open Fullscreen ↗

Try formatting and validating your JSON payload in real time with line-numbered error diagnostics and zero server tracking.

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

Is it safe to format sensitive JSON in an online tool? ▼

Yes, provided the tool runs strictly client-side. Client-side tools execute parsing inside your browser's local JavaScript V8 engine without sending any HTTP network requests to external servers. Always check the Network tab to confirm zero outgoing payloads.

Why does JSON.parse() reject trailing commas? ▼

The RFC 8259 specification explicitly defines arrays and objects as separated by commas, with no trailing comma allowed after the final value. Parsers adhere strictly to this grammar to ensure cross-language interoperability.

How can I fix invalid JSON with unquoted keys or single quotes? ▼

Standard JSON strictly mandates double quotes around all keys and string values. You can use an in-browser formatter that automatically replaces single quotes and wraps unquoted identifiers in double quotes before validating.

Security | Toolbox Guides & Articles

EXIF Metadata and Photo Privacy: What Your Images Reveal and How to Strip It

EXIF Metadata and Photo Privacy: What Your Images Reveal and How to Strip It

EXIF & Image Metadata Stripper

The Data You Did Not Mean to Publish

Where the Metadata Lives

In a JPEG

In a PNG

The Fields That Matter

What Platforms Actually Do

Stripping Without Quality Loss

A Practical Policy

Step-by-Step: Auditing and Stripping with Toolbox

Frequently Asked Questions

How TOTP 2FA Codes Work: RFC 6238 Math, Base32 Secrets, and Clock Drift

How TOTP 2FA Codes Work: RFC 6238 Math, Base32 Secrets, and Clock Drift

TOTP 2FA Authenticator Simulator

What TOTP Actually Is

The RFC 6238 Formula, Step by Step

Step 1: Derive the time counter

Step 2: Compute the HMAC

Step 3: Dynamic truncation

Step 4: Reduce to digits

Reference implementation

Base32 Secrets: Why Not Base64?

The Enrolment QR Code: otpauth:// URI

Clock Drift, Validation Windows, and Replay

Where TOTP Fits in 2026

Step-by-Step: Testing TOTP Codes with Toolbox

Frequently Asked Questions

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

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

RSA & ECC Keypair Generator

Two Ways to Build a Trapdoor

Security Strength: The Only Fair Comparison

Performance shape

Reading a PEM File

Generating a keypair with Web Crypto

The SSH format gap

Choosing an Algorithm in 2026

The RSA-OAEP Size Limit and Why Hybrid Encryption Exists

Signature padding: PSS or PKCS#1 v1.5?

Where post-quantum stands

Step-by-Step: Generating and Inspecting Keys with Toolbox

Frequently Asked Questions

AES-256-GCM Authenticated Encryption: How to Secure Data in the Browser

AES Encryption & Decryption Utility

What Is AES and How Does Modern Symmetric Cryptography Work?

The Critical Role of Block Cipher Modes

1. Electronic Codebook (ECB) — Fatally Insecure

2. Cipher Block Chaining (CBC) — Legacy Malleability

3. Galois/Counter Mode (GCM) — The Gold Standard AEAD

The Nonce/IV Mandate: Why 96-Bit IV Uniqueness Is Absolute

The Catastrophic “Two-Time Pad” Failure

Standard Operating Rules for IVs:

Architectural Comparison of AES Modes

Client-Side Web Crypto API Implementation

Step-by-Step: Encrypting Data in Toolbox

AES-256-GCM Authenticated Encryption: How to Secure Data in the Browser

The Enrolment QR Code: `otpauth://` URI

The `lastIndex` Trap