Toolbox Guides & Technical Articles | 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.

GST Calculation in India After GST 2.0: Slabs, Reverse GST, and CGST/SGST Splits

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

Free In-Browser Tool TOOLBOX UTILITY

GST Tax Calculator

Enter a base or inclusive amount, pick the slab, and read the taxable value, GST amount, and CGST/SGST split instantly. Billing figures stay in your browser.

Open GST Calculator →

What Changed with GST 2.0

For its first eight years, GST in India ran on four main slabs: 5%, 12%, 18%, and 28%, plus nil-rated goods and a compensation cess on select items. Classification disputes — which slab a product belonged to — were a routine source of litigation.

The 56th GST Council meeting replaced that structure. From 22 September 2025, the principal rates are:

Rate	Character	Typical coverage
0%	Nil	Unbranded fresh food staples, most healthcare and education services, many lifesaving drugs, individual life and health insurance premiums
5%	Merit	Mass-consumption goods and daily necessities
18%	Standard	Most services and the bulk of manufactured goods — the workhorse rate
40%	Demerit	Sin and luxury items such as pan masala, aerated and caffeinated beverages, larger motor cars, motorcycles above 350cc, yachts and personal aircraft, and betting or gambling services

Most items formerly at 12% moved to 5% or 18%; most at 28% moved to 18% or into the 40% demerit rate. Two caveats worth carrying:

Residual exceptions exist. A small set of items remains at the older rates pending separate notification, and compensation cess continues on tobacco products until the obligations funded by that cess are discharged, after which tobacco is expected to move to 40%.
Rate lookup is still per HSN/SAC code. No single slab table substitutes for checking the CBIC notification applicable to your specific goods or service.

What you get from this guide: the two formulas that cover every GST computation, the split logic, and the rounding discipline that makes an invoice reconcile.

Forward GST: Adding Tax to a Base Price

GST Amount = Taxable Value × (Rate / 100)
Total Payable = Taxable Value + GST Amount
 = Taxable Value × (1 + Rate / 100)

A consulting invoice for ₹50,000 at 18%:

GST = 50,000 × 0.18 = ₹9,000
Total payable = 50,000 + 9,000 = ₹59,000

Taxable value	5%	18%	40%
₹1,000	₹1,050	₹1,180	₹1,400
₹10,000	₹10,500	₹11,800	₹14,000
₹50,000	₹52,500	₹59,000	₹70,000

Reverse GST: Extracting Tax from an Inclusive Total

Retail prices, MRP-based billing, and most B2C receipts are tax-inclusive. Extracting the tax is division, not subtraction — and this is the single most common arithmetic error in small-business billing.

Taxable Value = Gross Amount / (1 + Rate / 100)
GST Amount = Gross Amount − Taxable Value

For a ₹1,180 inclusive total at 18%:

Taxable value = 1180 / 1.18 = ₹1,000.00
GST = 1180 − 1000 = ₹180.00

The wrong method, and why it matters:

Method	Computation	GST	Taxable value
❌ Subtract 18% of gross	1180 × 0.18	₹212.40	₹967.60
✅ Divide by 1.18	1180 / 1.18	₹180.00	₹1,000.00

The subtraction method overstates tax by ₹32.40 on a ₹1,180 bill — a 3% error on the tax line. Repeated across a filing period it produces a mismatch between your books, your GSTR-1 outward supplies, and the buyer’s Input Tax Credit claim.

Handy inclusive divisors

Rate	Divisor	Tax fraction of gross
5%	1.05	5/105 ≈ 4.7619%
18%	1.18	18/118 ≈ 15.2542%
40%	1.40	40/140 ≈ 28.5714%

CGST, SGST, UTGST, and IGST

GST is a dual levy. The total rate never changes with geography — only its division does, and the division follows the place of supply, not the physical route of the goods.

Supply type	Condition	Components at 18%
Intra-state	Supplier and place of supply in the same state/UT	9% CGST + 9% SGST
Intra-UT (no legislature)	Both within such a union territory	9% CGST + 9% UTGST
Inter-state	Different states, or an export/import	18% IGST

Intra-state, ₹1,00,000 at 18%:
 CGST = 1,00,000 × 9% = ₹9,000
 SGST = 1,00,000 × 9% = ₹9,000
 Total invoice = ₹1,18,000

Inter-state, same value and rate:
 IGST = 1,00,000 × 18% = ₹18,000
 Total invoice = ₹1,18,000

The buyer pays the same amount either way. The difference is which government receives it and, consequently, which credit ledger the buyer’s Input Tax Credit lands in — which is why a wrongly classified supply is corrected rather than ignored.

Rounding, Precision, and Reconciliation

Section 170 of the CGST Act requires the amount of tax, interest, penalty, or refund to be rounded to the nearest rupee, with 50 paise and above rounding up and below 50 paise rounding down.

The operational rule that follows: compute at full precision, round once at the end.

Line 1: ₹333.33 at 18% → 59.9994
Line 2: ₹333.33 at 18% → 59.9994
Line 3: ₹333.34 at 18% → 60.0012

Round each line, then sum : 60 + 60 + 60 = ₹180
Sum, then round once : 179.9994 → ₹180 ✅

The two agree here, but with different rates per line or more lines they diverge, and a buyer computing independently will land on the single-rounding figure. Keep at least two decimal places internally — and if you compute in a spreadsheet or JavaScript, remember that binary floating point makes 0.1 + 0.2 not exactly 0.3; work in paise as integers where the amounts are material.

Invoice fields the arithmetic must support

A compliant tax invoice needs, per line: HSN or SAC code, taxable value, rate, and the tax amount split by component; and at the invoice level: the total taxable value, total tax by component, and the rounded amount payable. A tool that shows only “GST amount” without the component split cannot produce a compliant intra-state invoice.

Worked Example: A Mixed-Rate Invoice

A retailer sells within their own state:

Item	Taxable value	Rate	GST	CGST	SGST
Packaged snacks	₹2,000	5%	₹100.00	₹50.00	₹50.00
Kitchen appliance	₹8,500	18%	₹1,530.00	₹765.00	₹765.00
Aerated beverages	₹1,200	40%	₹480.00	₹240.00	₹240.00
Total	₹11,700	—	₹2,110.00	₹1,055.00	₹1,055.00

Amount payable: ₹13,810. Note that GST is computed per line at that line’s rate — there is no blended average rate applied to the invoice total.

Step-by-Step: Using the Toolbox GST Calculator

Open the tool: visit the .
Choose the direction: add GST when you hold a base price, remove GST when you hold an inclusive retail total.
Select the slab that applies to the specific HSN or SAC code — verify it against the current CBIC notification rather than assuming last year’s rate.
Read the split: for an intra-state supply, use the CGST and SGST halves for the invoice; for inter-state, use the single IGST figure.
Round the payable total once, to the nearest rupee, and carry the unrounded taxable value into your books.
Cross-check the reverse case: feed the calculated total back through remove GST and confirm it returns your original base price — a fast sanity check against slab and direction mistakes.

Outcome: invoice figures that reconcile with the buyer’s Input Tax Credit claim and your GSTR filings, with the tax component derived by division rather than the subtraction shortcut.

Interactive Workbench LIVE

GST Calculation in India After GST 2.0: Slabs, Reverse GST, and CGST/SGST Splits

Open Fullscreen ↗

Enter a base or inclusive amount, pick the slab, and read the taxable value, GST amount, and CGST/SGST split instantly.

Initializing Workbench...

100% Client-Side RAM Sandbox

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

Launch Fullscreen →

This guide explains the arithmetic of GST. Rate applicability, exemptions, place-of-supply determination, and filing obligations depend on your specific facts — consult a chartered accountant or the CBIC notifications for compliance advice.

Related guides: · ·

FAQ

Frequently Asked Questions

What are the current GST slabs in India? ▼

Following the 56th GST Council meeting, the GST 2.0 structure took effect on 22 September 2025 with four principal rates: 0%, 5%, 18%, and a 40% demerit rate for sin and luxury goods. The former 12% and 28% slabs were largely folded into 5% and 18%, with a few residual items pending separate notification and compensation cess continuing on tobacco. Confirm the rate for a specific HSN or SAC code against the current CBIC notification.

How do I remove GST from a total that already includes it? ▼

Divide, don't subtract. Taxable value = gross / (1 + rate/100), and GST = gross − taxable value. For ₹1,180 inclusive at 18%, the taxable value is ₹1,000 and the GST is ₹180. Subtracting 18% of the gross gives ₹212.40, which overstates the tax on every inclusive-price invoice.

When is GST split into CGST and SGST instead of IGST? ▼

It depends on the place of supply, not the physical route. Intra-state supply splits the total equally into Central GST and State GST, so 18% becomes 9% plus 9%. Inter-state supply is charged wholly as Integrated GST and apportioned later by the Centre. A union territory without a legislature uses UTGST in place of SGST.

How should GST amounts be rounded on an invoice? ▼

Compute the tax at full precision, then round the payable amount to the nearest rupee under Section 170 of the CGST Act, with 50 paise and above rounding up. Round once at the invoice total rather than per line, since per-line rounding accumulates drift that will not reconcile with the buyer's figures or your GSTR filings.

HMAC-SHA256 Webhook Signature Verification: RFC 2104 Internals and Provider Formats

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

Interactive Workbench LIVE

HMAC-SHA256 Webhook Signature Verification: RFC 2104 Internals and Provider Formats

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

HMAC Signature Generator & Verifier

Paste a payload and secret, choose SHA-256, SHA-384, SHA-512, or SHA-1, and compare the computed digest against the signature you received.

Open HMAC Generator & Verifier →

The Problem HMAC Solves

You receive an HTTP POST claiming to be a payment confirmation. The body says an order was paid. Acting on it moves inventory and money. Two questions must be answered before your code touches the database:

Authenticity — did this come from the provider, or from anyone who found the endpoint URL?
Integrity — is the body byte-for-byte what the provider sent, or was an amount edited in transit?

A Keyed-Hash Message Authentication Code answers both. The provider holds a secret, you hold the same secret, and the provider attaches a tag that only a holder of that secret could have produced over that exact payload.

What you get from this guide: the construction, the specific attack that motivates it, working verification code for three major providers, and the four mistakes that cause almost every “signature invalid” incident.

The RFC 2104 Construction

HMAC(K, m) = H( (K' XOR opad) || H( (K' XOR ipad) || m ) )

Term	Definition
`H`	Underlying hash function (SHA-256, SHA-512, SHA-1)
`B`	Hash block size in bytes — 64 for SHA-1/SHA-224/SHA-256, 128 for SHA-384/SHA-512
`K'`	The key, normalised to exactly `B` bytes
`ipad`	Byte `0x36` repeated `B` times (inner pad)
`opad`	Byte `0x5C` repeated `B` times (outer pad)
`

Key normalisation matters: a key shorter than B is right-padded with zero bytes; a key longer than B is first hashed with H, and that digest becomes the key. This means a 200-character secret and its SHA-256 digest produce identical HMACs — a detail that occasionally explains why two “different” secrets validate the same payload.

Why not `H(secret || message)`?

Because SHA-1 and the SHA-2 family are Merkle–Damgård constructions that expose their internal state as the output digest. Given H(secret || message) and the length of secret || message, an attacker can resume the hash from that state and compute a valid digest for secret || message || padding || evil — without ever learning the secret. That is a length-extension attack, and it turns a naive “signature” into a forgery oracle.

Block sizes and digest lengths

Hash function	Block size `B`	Digest	Hex characters
MD5	64 bytes	128 bits	32
SHA-1	64 bytes	160 bits	40
SHA-256	64 bytes	256 bits	64
SHA-384	128 bytes	384 bits	96
SHA-512	128 bytes	512 bits	128

The two pads are the whole trick: ipad and opad differ in exactly half their bits, so the inner and outer passes behave like two independent keyed functions.

The double-pad nesting in HMAC means the attacker only ever sees the output of the outer hash, whose input they cannot control or extend. This is why RFC 2104 (1997) and FIPS PUB 198-1 (2008) both standardise the nested form, and why crypto.createHmac exists in every standard library.

Provider Formats Compared

Provider	Header	Encoding	Signed data	Secret
Stripe	`Stripe-Signature`	hex, inside `t=…,v1=…`	`"{timestamp}.{raw_body}"`	endpoint secret (`whsec_…`)
GitHub	`X-Hub-Signature-256`	hex, prefixed `sha256=`	raw body	webhook secret
Shopify	`X-Shopify-Hmac-SHA256`	Base64	raw body	app client secret

All three use HMAC-SHA256 and all three require the unmodified raw body.

Stripe

The header carries a timestamp and one or more scheme-prefixed signatures:

Stripe-Signature: t=1492774577,v1=5257a869e7ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd

Verification, per Stripe’s manual procedure: split the header on , then =, build signed_payload as the timestamp, a literal ., and the raw JSON body, compute HMAC-SHA256 with the endpoint secret, compare in constant time, and reject if the timestamp is outside your tolerance. Stripe’s official libraries default to a five-minute tolerance, and Stripe advises ignoring any scheme that is not v1 to prevent downgrade attacks. During a secret roll, an endpoint can have two active secrets and the header then carries one v1 signature per secret — so compare against all v1 values, not just the first.

import crypto from "node:crypto";

export function verifyStripe(rawBody, header, secret, toleranceSec = 300) {
 const parts = Object.fromEntries(
 header.split(",").map((kv) => kv.split("=").map((s) => s.trim()))
 );
 const timestamp = Number(parts.t);
 if (!timestamp) return false;

 // Freshness: a valid signature is not a fresh one.
 if (Math.abs(Math.floor(Date.now() / 1000) - timestamp) > toleranceSec) return false;

 const expected = crypto
 .createHmac("sha256", secret)
 .update(`${timestamp}.${rawBody}`, "utf8")
 .digest("hex");

 const received = header
 .split(",")
 .filter((kv) => kv.trim().startsWith("v1="))
 .map((kv) => kv.trim().slice(3));

 return received.some((sig) => timingSafeEqualHex(expected, sig));
}

function timingSafeEqualHex(a, b) {
 const ab = Buffer.from(a, "hex");
 const bb = Buffer.from(b, "hex");
 return ab.length === bb.length && crypto.timingSafeEqual(ab, bb);
}

GitHub

export function verifyGithub(rawBody, header, secret) {
 const expected =
 "sha256=" + crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
 const a = Buffer.from(expected);
 const b = Buffer.from(header ?? "");
 return a.length === b.length && crypto.timingSafeEqual(a, b);
}

Shopify

export function verifyShopify(rawBody, header, clientSecret) {
 const expected = crypto
 .createHmac("sha256", clientSecret)
 .update(rawBody, "utf8")
 .digest("base64");
 const a = Buffer.from(expected, "base64");
 const b = Buffer.from(header ?? "", "base64");
 return a.length === b.length && crypto.timingSafeEqual(a, b);
}

The Four Failure Modes

1. The body was parsed before you hashed it

The most common cause by a wide margin. express.json(), Django’s request handling, and Next.js route defaults may hand you a re-serialised object. Re-encoding {"a":1.0} as {"a":1}, reordering keys, or normalising Unicode escapes all change the byte string and therefore the digest. Stripe states the requirement plainly: the raw body must be the string it sent, in UTF-8, unchanged.

// Order matters. Mount the raw-body webhook route BEFORE the JSON parser.
app.post("/webhooks/stripe", express.raw({ type: "application/json" }), handler);
app.use(express.json());

2. Non-constant-time comparison

expected === received returns as soon as it hits a differing byte. That timing difference is measurable across enough requests and leaks the expected digest byte by byte. Use crypto.timingSafeEqual, hmac.compare_digest (Python), or hash_equals (PHP). Compare decoded bytes of equal length — timingSafeEqual throws on length mismatch, so check length first.

3. No replay protection

A valid signature says “this was authentic when created”. It says nothing about when. Sign a timestamp (Stripe’s model) and enforce a tolerance, or store processed delivery IDs and drop repeats. Stripe also warns against setting the tolerance to 0, which disables the recency check entirely.

4. Signature comparison as the only gate

Also validate that the event type is one you handle, return 2xx quickly and process asynchronously, and treat delivery as at-least-once — providers retry, and duplicate events are normal. Stripe explicitly does not guarantee ordering, so deduplicate on event ID rather than trusting timestamps.

Hex, Base64, or Base64url — Match the Provider Exactly

One 32-byte HMAC-SHA256 tag has several textual forms, and mismatched encoding is the second most common cause of failed verification after raw-body mistakes.

Encoding	Length for SHA-256	Typical users
Lowercase hex	64 characters	GitHub, Stripe, most REST APIs
Base64	44 characters (with `=` padding)	Shopify, Slack legacy, AWS headers
Base64url	43 characters (no padding)	JWT `HS256` signature segment

A digest that “looks wrong” but is the right length in a different alphabet is an encoding bug, not a secret mismatch. For the encoding mechanics themselves see the ; for the JWT variant, the .

Computing HMAC in the Browser

SubtleCrypto supports HMAC natively, so a signature can be produced or checked with no network exposure at all:

async function hmacSha256Hex(secret, message) {
 const enc = new TextEncoder();
 const key = await crypto.subtle.importKey(
 "raw", enc.encode(secret),
 { name: "HMAC", hash: "SHA-256" }, false, ["sign", "verify"]
 );
 const sig = await crypto.subtle.sign("HMAC", key, enc.encode(message));
 return [...new Uint8Array(sig)].map((b) => b.toString(16).padStart(2, "0")).join("");
}

For verification prefer crypto.subtle.verify("HMAC", key, signatureBytes, data) — it compares internally instead of exposing you to a naive ===.

Operational Checklist

Generate keys randomly. 32 bytes from crypto.getRandomValues or openssl rand -hex 32 — never a passphrase.
Sign the exact bytes on the wire. No re-serialisation, trimming, or charset conversion.
Compare in constant time. crypto.timingSafeEqual, Python’s hmac.compare_digest, PHP’s hash_equals, or subtle.verify.
Include a timestamp and reject stale requests. HMAC proves authenticity, not freshness.
Support two active secrets during rotation. Accept either tag while migrating, then retire the old key — this is exactly why Stripe can send one v1 signature per active secret.
Never log the secret or put it in a URL. Query strings land in access logs, proxies, and browser history.

Choosing the Hash

Algorithm	Digest	Verdict for new work
HMAC-SHA256	32 bytes	Default. Universal library support, ample margin.
HMAC-SHA512	64 bytes	Fine; faster than SHA-256 on 64-bit CPUs for large payloads.
HMAC-SHA384	48 bytes	Use when a compliance profile requires it.
HMAC-SHA1	20 bytes	Legacy interop only (older GitHub `X-Hub-Signature`, TOTP). Not broken inside HMAC, but do not choose it for new protocols.

HMAC-SHA1 remains safe as an authenticator because HMAC does not depend on collision resistance — the same reason . Even so, auditors flag it, so new designs should start at SHA-256. For plain (unkeyed) integrity digests, see the .

Step-by-Step: Debugging a Failing Signature with Toolbox

Capture the raw body from your server logs or the provider’s delivery inspector — copy the exact bytes, not a pretty-printed version.
Open the tool: visit the .
Paste the payload and the signing secret, and select SHA-256.
For Stripe, prepend the timestamp: enter 1492774577.{"id":"evt_…"} — timestamp, dot, raw body — matching the signed_payload construction.
Compare digests: place the provider’s header value next to the computed digest. A hex/Base64 mismatch means an encoding bug; a completely different digest means the body was mutated or the wrong secret is in use.

Outcome: you localise the fault to one of three causes — wrong secret, mutated body, or wrong signed-payload construction — in a couple of minutes, without redeploying to add log statements.

Related guides: · ·

FAQ

Frequently Asked Questions

Why is HMAC used instead of simply hashing the secret and the message together? ▼

SHA-1 and SHA-2 are Merkle-Damgard constructions vulnerable to length extension: given H(secret || message) and the input length, an attacker can produce a valid digest for message || padding || attacker_data without knowing the secret. HMAC's nested form, H((K XOR opad) || H((K XOR ipad) || message)), prevents that, which is why RFC 2104 and FIPS PUB 198-1 specify it.

Why does webhook signature verification fail when my framework parses JSON automatically? ▼

The digest covers the exact bytes the provider sent. Body parsers re-serialise JSON and can reorder keys or change whitespace, number, and Unicode formatting, producing a different byte string and digest. Capture the raw body before parsing middleware runs — in Express, mount the webhook route before express.json() or use express.raw() on that route.

What is the difference between HMAC and a digital signature? ▼

HMAC is symmetric: the same secret creates and verifies the tag, so any verifier can also forge. It proves the sender holds the shared secret. RSA or ECDSA signatures are asymmetric — the private key signs, the public key only verifies — adding non-repudiation. Webhooks use HMAC because a shared secret already exists and HMAC is far faster.

Do I still need a timestamp check if the signature is valid? ▼

Yes. A valid signature proves authenticity and integrity, not freshness. Without a signed timestamp an intercepted request can be replayed indefinitely. Stripe signs a timestamp and its libraries default to a five-minute tolerance; where no timestamp is signed, deduplicate on the delivery or event ID.

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.

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

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

Interactive Workbench LIVE

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

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

HTTP Header Security Auditor

Paste a raw response, get an A+ to F hardening grade with per-header findings, and export a matching Nginx or Apache configuration snippet.

Audit Your HTTP Headers →

Headers Are the Cheapest Security You Will Ever Deploy

Most web hardening work requires code changes, reviews, and regression testing. Security headers require a configuration line at the edge and cost nothing at runtime.

They are also the layer most often left at framework defaults — which is why a first audit of a mature application so often returns a grade of D or F.

The table below is the shortlist. Everything after it is detail.

Header	Blocks	Priority
`Content-Security-Policy`	Cross-site scripting, data injection	Critical
`Strict-Transport-Security`	Protocol downgrade, SSL stripping	Critical
`X-Content-Type-Options`	MIME-sniffing confusion attacks	Critical
`frame-ancestors` / `X-Frame-Options`	Clickjacking, UI redress	High
`Referrer-Policy`	URL and token leakage via `Referer`	High
`Permissions-Policy`	Unwanted camera, mic, geolocation access	Medium
`COOP` / `COEP` / `CORP`	Cross-origin leaks; enables isolation	Situational
`Cache-Control: no-store`	Sensitive data cached on shared devices	Situational

Content-Security-Policy: The One That Does the Work

CSP tells the browser which sources of script, style, and other content are legitimate. Done properly, it turns a cross-site scripting bug from a full account takeover into a blocked console error.

The Modern Strict Policy

Content-Security-Policy:
 default-src 'self';
 script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
 object-src 'none';
 base-uri 'self';
 frame-ancestors 'none';
 require-trusted-types-for 'script';

Each line earns its place:

'nonce-{RANDOM}' — a fresh, cryptographically random value of at least 128 bits, generated per response and echoed on every legitimate <script nonce="...">. A reused or predictable nonce is no protection at all.
'strict-dynamic' — lets a nonce-approved script load further scripts it creates programmatically, and causes host allowlists to be ignored. This matters because allowlist-based policies are routinely bypassable through JSONP endpoints and open redirects on allowlisted CDNs.
https: 'unsafe-inline' — a deliberate fallback for browsers too old to understand nonces. Modern browsers ignore 'unsafe-inline' whenever a nonce or hash is present, which is specified behaviour, so this line is backward compatibility rather than a hole.
object-src 'none' — removes the <object>, <embed>, and legacy plugin bypass surface. There is almost never a reason to allow it.
base-uri 'self' — prevents an injected <base> tag from redirecting every relative URL on the page to an attacker’s host.
frame-ancestors 'none' — the modern clickjacking control, superseding X-Frame-Options.

Roll It Out in Report-Only Mode First

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;

The Report-Only variant logs violations without blocking anything. Run it for a full traffic cycle — including whatever nightly and monthly jobs render pages — before switching to the enforcing header. Deploying an untested CSP straight to enforcement is the fastest way to take your own site down.

Directives That Do Not Behave as Expected

default-src is not a universal fallback. It does not cover base-uri, frame-ancestors, form-action, or sandbox. Set those explicitly.
'unsafe-eval' re-enables eval and the string form of setTimeout. Some older bundlers and templating libraries need it; treat needing it as technical debt.
A meta http-equiv CSP silently drops frame-ancestors, report-uri, and sandbox, and only applies from the point the parser reads the tag. Send CSP as a real header.

Strict-Transport-Security

HSTS (RFC 6797) instructs the browser to refuse plaintext HTTP for a host for a fixed period — closing the window in which a first plaintext request can be intercepted and stripped.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Token	Meaning	Notes
`max-age`	Seconds to remember the HTTPS-only rule	Required. 63072000 = two years
`includeSubDomains`	Applies to every subdomain	Verify every subdomain serves HTTPS first
`preload`	Requests inclusion in browser preload lists	Not part of RFC 6797; see hstspreload.org

Preload eligibility, per hstspreload.org, requires a valid certificate, an HTTP-to-HTTPS redirect on the same host, and a header on the HTTPS root with max-age of at least 31536000 plus both includeSubDomains and preload.

Two operational warnings:

Preloading is hard to undo. Removal requests take effect only as browsers ship new versions, which can mean months. A subdomain that cannot serve HTTPS becomes unreachable for users whose browsers hold the preload entry.
Ramp max-age upward. Start at 300, then a day, then a week, then a year. A mistake at max-age=63072000 is a two-year commitment for every visitor who received it.

HSTS is only sent over HTTPS. Browsers ignore it on a plaintext response, by design.

Clickjacking, Sniffing, and Referrer Leakage

`X-Content-Type-Options: nosniff`

One value, no options, no downside. It stops the browser from second-guessing your Content-Type, which is what turns an uploaded .txt file containing markup into stored XSS. Send it on every response.

`X-Frame-Options`

X-Frame-Options: DENY # or SAMEORIGIN

Defined in RFC 7034 and superseded by CSP frame-ancestors. Note that the ALLOW-FROM value was never implemented by Chrome or Safari — to permit a specific external framer, you must use frame-ancestors https://partner.example. Sending both headers is common and harmless, as long as they do not contradict each other.

`Referrer-Policy`

Referrer-Policy: strict-origin-when-cross-origin

This is now the browser default in Chrome and Firefox, but sending it explicitly documents the intent and protects against a proxy or framework overriding it. Cross-origin requests then carry only the origin — no path, no query string, no accidental token disclosure. Use no-referrer for pages whose URLs are themselves sensitive, such as password-reset links.

`Permissions-Policy`

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

An empty allowlist () denies the feature to the document and every frame it embeds. Deny what you do not use — a third-party script in an iframe cannot prompt for a camera it has no permission to request. This header replaces the older Feature-Policy, which used a different value syntax.

Cross-Origin Isolation: COOP, COEP, CORP

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin

COOP same-origin severs the window.opener relationship with cross-origin pages, closing a family of tab-nabbing and cross-window attacks.
COEP require-corp requires every cross-origin subresource to opt in explicitly, via CORS or Cross-Origin-Resource-Policy.
CORP is the opt-in mechanism resources use to declare who may embed them.

COOP plus COEP together put the document in a cross-origin isolated state, which is a prerequisite for SharedArrayBuffer and high-resolution timers. That makes them mandatory for WebAssembly-heavy applications — and also the pair most likely to break third-party embeds. COOP alone is a safe, valuable default; adopt COEP only when you need isolation and have audited every embedded resource.

Headers to Delete

Hardening is subtraction as well as addition.

Header	Action	Reason
`X-XSS-Protection`	Remove	The Chrome XSS Auditor it controlled was removed; the filter itself introduced information-leak bugs. OWASP advises against it.
`X-Powered-By`	Remove	Discloses runtime and version, handing an attacker a CVE shortlist
`Server`	Minimise	`Apache/2.4.41 (Ubuntu)` names the exact patch level to target
`X-AspNet-Version`	Remove	Same disclosure problem
`Public-Key-Pins`	Remove	HPKP is obsolete and removed from browsers; use Certificate Transparency and CAA records

Also remember Cache-Control: no-store on any authenticated response. A shared or kiosk browser retaining an account page in its back-forward cache is a real disclosure, and no-cache alone does not prevent storage.

Server Configuration Pitfalls

Nginx: inheritance and error responses

add_header Content-Security-Policy "default-src 'self'" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Two behaviours cause almost every “header missing on some pages” report:

add_header directives are not merged across levels. A single add_header inside a location block discards all inherited add_header directives from server and http. Repeat the full set in that block.
Without always, headers are only added to successful responses. Your 404 and 500 pages ship unprotected — and those are exactly the pages most likely to reflect user input.

Apache

Header always set Content-Security-Policy "default-src 'self'"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always unset X-Powered-By

Header always set is the equivalent of Nginx’s always, covering error responses too.

A Note on CORS

Access-Control-Allow-Origin is not a hardening header — it relaxes the same-origin policy. And Access-Control-Allow-Origin: * cannot be combined with Access-Control-Allow-Credentials: true; browsers reject that pairing. Reflecting an arbitrary Origin header back while allowing credentials is a serious vulnerability, not a configuration convenience.

Step-by-Step: Auditing with Toolbox

Capture your real headers. Run curl -sSI https://yoursite.example or copy the response headers from your browser’s Network panel.
Open the tool: visit the .
Paste the raw response into the input box, or start from one of the built-in presets to see what a hardened and an unhardened response look like side by side.
Read the Audit tab for the letter grade from A+ to F and the per-header findings behind it.
Check the Table tab for the parsed name-value view, which is the quickest way to spot a duplicated or malformed header.
Export from the Config tab — select Nginx or Apache and copy the generated hardening snippet straight into your server or edge configuration.
Re-audit after deploying, and check a 404 as well as a 200. Missing headers on error responses is the single most common regression.

Parsing and grading happen entirely in your browser; the tool never fetches your site or transmits the headers you paste. That means you can safely audit a staging environment behind a VPN, or a response containing session cookies.

Two related hardening steps sit just outside the header layer: verifying that inbound webhooks are genuinely signed, covered in the , and validating token claims properly, covered in the .

FAQ

Frequently Asked Questions

Which HTTP security headers actually matter most? ▼

Four carry most of the value. Content-Security-Policy limits which scripts can execute and is the primary defence against cross-site scripting. Strict-Transport-Security forces HTTPS and prevents downgrade attacks. X-Content-Type-Options with the value nosniff stops MIME confusion attacks. Either CSP frame-ancestors or X-Frame-Options prevents clickjacking. Referrer-Policy and Permissions-Policy are valuable but reduce data leakage rather than blocking an active attack.

Why is unsafe-inline ignored in my Content-Security-Policy? ▼

That behaviour is specified, not a bug. When a directive contains a nonce or a hash source expression, the browser ignores unsafe-inline for that directive. The design intent is that a page can send unsafe-inline as a fallback for very old browsers while modern browsers enforce the stricter nonce-based policy. If you want inline scripts to run in a modern browser, you must give each one the matching nonce or hash.

What does HSTS preload require? ▼

To be accepted onto the browser preload list at hstspreload.org, a site must serve a valid certificate, redirect all HTTP traffic to HTTPS on the same host, and send a Strict-Transport-Security header on the HTTPS root with a max-age of at least 31536000 seconds, plus the includeSubDomains and preload tokens. Preloading is difficult to reverse quickly, so confirm that every subdomain can serve HTTPS before submitting.

Is X-Frame-Options still needed if I use CSP frame-ancestors? ▼

It is largely redundant in current browsers, which prefer frame-ancestors when both are present. Many organisations still send both, because X-Frame-Options remains the header that legacy scanners, corporate proxies, and older embedded browsers understand. Sending both is harmless provided they agree; a DENY value alongside a permissive frame-ancestors list is a configuration conflict waiting to confuse an audit.

Can I set security headers with an HTML meta tag instead? ▼

Only partially. A Content-Security-Policy can be delivered via meta http-equiv, but the frame-ancestors, report-uri, and sandbox directives are ignored in that form, and the policy applies only after the parser reaches the tag. No other security header works as a meta tag at all. Send security headers from the server or the edge, where they cover every response including redirects and errors.

LLM Token Counting and Cost Estimation: BPE Mechanics, Context Budgets, and Real Math

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

QUICK ANSWER RFC SPECIFICATION SUMMARY

100% Client-Side

A token is a subword unit produced by the model's tokenizer, typically trained with byte-pair encoding, so cost and context limits are measured in tokens rather than words. English prose averages roughly four characters per token, but code, JSON, and non-Latin scripts run far higher. API cost equals input tokens multiplied by the input rate plus output tokens multiplied by the output rate, where output is normally three to five times more expensive. In multi-turn chat the whole history is resent every turn, so cumulative input grows roughly quadratically with turn count — which is why prompt caching and batch processing cut bills more than shortening prompts does.

Difficulty: Intermediate Time: 8 Mins Privacy: 100% Client-Side RAM Standard: Byte-Pair Encoding (Sennrich et al., 2016)

Interactive Workbench LIVE

LLM Token Counting and Cost Estimation: BPE Mechanics, Context Budgets, and Real Math

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

LLM Token Budget & Cost Matrix

Paste a prompt to estimate token counts and projected spend across model tiers. Proprietary prompts and system instructions stay in browser memory.

Open Token & Cost Calculator →

Why Tokens, Not Words

Language models do not read characters or words. They read integers drawn from a fixed vocabulary — typically 100,000 to 300,000 entries — where each entry maps to a chunk of bytes. That mapping is learned, not designed, and it is why token accounting feels arbitrary until you see the algorithm.

Byte-Pair Encoding (BPE) builds the vocabulary greedily. Start with individual bytes, count adjacent pairs across a training corpus, merge the most frequent pair into a new symbol, and repeat until the vocabulary reaches its target size. Frequent sequences — the, ing, function, https — collapse into single tokens. Rare sequences stay fragmented.

Two consequences follow directly:

Common English is cheap; unusual strings are expensive. A UUID such as f47ac10b-58cc-4372-a567-0e02b2c3d479 has essentially no frequent substrings, so it tokenizes close to one token per few characters — often 20 or more tokens for 36 characters. Generate them with the and you will see the cost of putting many in a prompt.
Structure is not free. Every {, ", : and newline in a JSON payload is billed. The same data as compact prose can cost meaningfully fewer tokens than as pretty-printed JSON.

What you get from this guide: an accurate estimation method, a corrected model of multi-turn spend, and the specific levers that lower cost without degrading output.

Counting Tokens Properly

The heuristic and its limits

Content type	Approximate tokens
English prose	~1 token per 4 characters (~0.75 words)
Source code	~1 token per 2.5-3.5 characters
Minified JSON	~1 token per 2.5-3 characters
CJK / Devanagari / Cyrillic	Frequently 1-2 tokens per character
Hashes, UUIDs, Base64	Near one token per 2-3 characters

The non-Latin row is the one that breaks budgets. A Hindi or Japanese support corpus can cost several times what an English corpus of the same visual length costs, which matters for anyone building for Indian or East Asian markets.

Count exactly, for real budgets

Every major provider exposes a counting path — use it rather than a third-party tokenizer that may not match the model you are calling:

// Anthropic: authoritative count for the exact model you will call.
const { input_tokens } = await client.messages.countTokens({
 model: "claude-opus-5",
 system: SYSTEM_PROMPT,
 messages,
});

Anthropic’s own guidance is explicit that tokenizers differ across model generations: the tokenizer introduced with Opus 4.7 can consume roughly 1x to 1.35x the tokens of the earlier one for identical input, so a migration re-baselines every budget you built.

The Cost Formula

Cost = (input_tokens / 1,000,000) × input_rate
 + (output_tokens / 1,000,000) × output_rate

Output is the expensive side — commonly three to five times the input rate — because it is generated sequentially. On models with reasoning or “thinking” enabled, internal reasoning tokens are billed as output even when the text is not returned to you, which is the single most common surprise on a first bill.

Published rates, checked September 2026

Per million tokens, standard (non-batch) processing. Verify against the provider’s own pricing page before committing a budget — these change, and several current rates are explicitly promotional.

Provider	Model	Input	Output	Note
Anthropic	Claude Opus 5	$5.00	$25.00	1M context
Anthropic	Claude Sonnet 5	$2.00	$10.00	1M context
Anthropic	Claude Haiku 4.5	$1.00	$5.00	200K context
OpenAI	gpt-6-astra	$10.00	$50.00	—
OpenAI	gpt-5.6-sol	$4.00	$20.00	Promotional pricing published at least through 21 Nov 2026
OpenAI	gpt-5.6-terra	$2.00	$12.00	—
OpenAI	gpt-5.5	$5.00	$30.00	Context under 272K
Google	Gemini 3.8 Flash	$0.75	$3.75	Rate published through 31 Dec 2026
Google	Gemini 3.1 Pro Preview	$2.00	$12.00	Rate varies by prompt length band

Note the pattern rather than the exact numbers: a frontier tier near $5-10 input, a workhorse tier near $2, and a fast tier under $1. Price your workload against the tier, then confirm the current figure.

A worked example

A support assistant: 1,200-token system prompt, 400-token user message, 300-token reply, 50,000 conversations per month, on a $2 / $10 model.

Input per call : 1,600 tokens → 1,600 × 50,000 = 80,000,000 tokens
Output per call : 300 tokens → 300 × 50,000 = 15,000,000 tokens

Input cost : 80 × $2.00 = $160.00
Output cost : 15 × $10.00 = $150.00
Total = $310.00 / month

Now cache the 1,200-token system prompt. If cache reads bill at roughly a tenth of the input rate, that portion drops from $120 to about $12, taking the total to roughly $200 — a 35% cut with no change to the prompt’s content or the model’s behaviour.

The Multi-Turn Multiplier

The single largest estimation error in production LLM apps: the API is stateless. There is no server-side conversation. Every turn resends the full history.

Turn	New input	Total input billed this turn
1	500	500
2	500	1,000
3	500	1,500
…	…	…
10	500	5,000

Cumulative input across ten turns is 27,500 tokens, not 5,000. Cost grows with roughly the square of the turn count. Three mitigations, in order of preference:

Cache the stable prefix. Order the request as tools, then system, then messages, and keep everything volatile — timestamps, request IDs, the current question — after the last cache breakpoint. A single changed byte in the prefix invalidates everything after it.
Summarise or compact old turns rather than resending raw transcripts, once history exceeds what the task actually needs.
Trim what was never needed. Full tool schemas, entire retrieved documents, and verbose few-shot examples are often resent every turn for value that decayed after turn two.

Context Windows Are a Separate Constraint

Cost and capacity are different limits. A 1M-token context window does not mean filling it is wise:

Filling the window is expensive. One million input tokens at $2 per million is $2 for a single request.
Retrieval quality can degrade with very large, weakly relevant context; a focused 8K prompt frequently outperforms a padded 200K one.
Output caps are separate. A model with a 1M input window may cap a single response far lower, so “it fits in context” says nothing about how much it can write back.

Budget three numbers independently: input tokens per call, output tokens per call, and calls per month. Optimising the wrong one is why prompt-shortening exercises so often fail to move the bill.

Step-by-Step: Building a Token Budget with Toolbox

Collect real inputs, not samples you wrote by hand — export ten to twenty actual prompts including system text and tool definitions.
Open the tool: visit the and paste them one at a time.
Record the median and the 90th percentile, not just the average. Tail requests drive both cost spikes and context overflow errors.
Multiply by real call volume and add the multi-turn factor: for an n-turn conversation, cumulative input is roughly n(n+1)/2 times the per-turn increment.
Confirm with the provider’s own counter before signing off a budget, since only that number matches what you will be billed.
Re-baseline after any model change. A tokenizer change alone can move counts by up to a third.

Outcome: a defensible monthly cost projection with a named optimisation order — cache the prefix, batch what can wait, and only then touch model tier or reasoning effort.

Before pasting production prompts into any estimator, remove secrets and personal data — see the .

Related guides: · ·

FAQ

Frequently Asked Questions

Why do the same words cost a different number of tokens in different models? ▼

Each model family ships its own tokenizer vocabulary, trained by byte-pair encoding or a SentencePiece variant on its own corpus. A term seen often during training becomes one token; another vocabulary may split it into three. Counts therefore differ across providers and even across generations from one provider — Anthropic notes the tokenizer introduced with Opus 4.7 can use roughly 1x to 1.35x the tokens of its predecessor.

Is the rule that one token equals four characters reliable? ▼

Only as a rough first pass for English prose, where about four characters or 0.75 words per token holds. It fails for code and JSON, where punctuation and field names fragment heavily, for non-Latin scripts that can cost several tokens per character, and for hashes or UUIDs that tokenize nearly per character. Budget from measured counts.

Why is my bill higher than my per-request estimate suggested? ▼

Chat APIs are stateless, so every turn resends the whole conversation as input and cumulative input grows roughly with the square of the turn count. Add system prompts, tool definitions, retrieved documents, and reasoning tokens billed as output, and resent context usually dominates spend rather than new output.

What is the cheapest safe way to cut LLM cost without hurting quality? ▼

Prompt caching first, because it changes price rather than behaviour: keep a stable prefix of system prompt, tool definitions, and reference documents ahead of the volatile part of the request. Then use asynchronous batch processing for non-urgent work, commonly at half price. Only after that consider lower reasoning effort or a smaller model, since those can change output quality.

Merging and Splitting PDFs Locally: File Structure, What Survives, What Breaks

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

Interactive Workbench LIVE

Merging and Splitting PDFs Locally: File Structure, What Survives, What Breaks

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

PDF Merger & Page Combiner

Drag in multiple PDFs, order them, and export a single document. Parsing and assembly happen in browser memory, so contracts and statements are never uploaded.

Open PDF Merger →

Why PDF Editing Behaves Strangely

Most file formats are a linear stream you read from start to end. PDF is not. It is an object graph — a set of numbered objects that reference each other — plus an index telling a reader where each object lives in the file. That design is why a 400-page PDF opens instantly on page 300, and also why “deleting” a page does not necessarily delete anything.

The format is standardised as ISO 32000-1 (PDF 1.7) and ISO 32000-2:2020 (PDF 2.0). Understanding four structures explains every merge and split behaviour you will encounter.

What you get from this guide: a working mental model of the file, a checklist of what survives each operation, and the specific verification step that prevents accidentally shipping a “removed” confidential page.

The Four Structures That Matter

1. Objects

Everything is an object with a number and generation: dictionaries, arrays, numbers, strings, names, and streams (compressed binary blobs holding page content, fonts, and images).

3 0 obj
<< /Type /Page
 /Parent 2 0 R
 /MediaBox [0 0 595.28 841.89]
 /Resources << /Font << /F1 7 0 R >> >>
 /Contents 4 0 R >>
endobj

7 0 R is an indirect reference: “object 7, generation 0”. A page does not contain its font; it points at one. That indirection is the entire reason merging is cheap and also the reason resources get duplicated.

2. The cross-reference table

At the end of the file, the xref table (or, in modern files, a compressed xref stream) maps each object number to a byte offset. The trailer points to the catalog and to the xref itself:

trailer
<< /Size 12 /Root 1 0 R >>
startxref
14127
%%EOF

A reader opens a PDF by seeking to the end, reading startxref, jumping to the table, and only then loading the objects it needs.

3. The page tree

Pages are not a flat list. The catalog points to a /Pages node, which contains /Kids — pages or further nodes — and a /Count:

1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj
2 0 obj << /Type /Pages /Kids [3 0 R 5 0 R 9 0 R] /Count 3 >> endobj

This is what merging and splitting actually manipulate. A merge creates a new /Pages node whose /Kids array lists page objects copied from several sources, renumbering objects to avoid collisions and rewriting every reference. A split creates a catalog whose /Kids names only the pages you kept. Page content streams are copied verbatim, which is why merging is lossless for what is drawn on the page.

4. Incremental updates

PDF allows a writer to append: leave the original bytes untouched, write changed objects at the end, and add a new xref section that supersedes the old entries. Readers follow the newest table, so the document appears edited.

The consequence is blunt: the old objects are still in the file. A page “deleted” by an incremental update can be recovered by a parser that reads the previous xref generation, and its text can sometimes be pulled out by a naive extractor that scans all streams. Redacting by drawing a black rectangle over text is the same failure in a different costume — the text object remains underneath.

What Survives Merge and Split

Element	Merge	Split	Notes
Page content (text, vectors)	✅	✅	Content streams copied byte-for-byte
Embedded fonts	✅	✅	Copied per source; often duplicated
Images / XObjects	✅	✅	Duplicated unless the library deduplicates by hash
Page size and rotation	✅	✅	`/MediaBox` and `/Rotate` are page-level
Bookmarks / outlines	⚠️	⚠️	Document-scope; frequently dropped or dangling
Internal links / named destinations	⚠️	❌	Break when the target page leaves the document
AcroForm fields	⚠️	⚠️	Field name collisions on merge; hierarchy loss on split
Digital signatures	❌	❌	Invalidated — the signed byte range no longer exists
Tags / accessibility structure	⚠️	⚠️	The `/StructTreeRoot` is document-scope; often lost
XMP / document metadata	⚠️	⚠️	Usually taken from the first input or regenerated
JavaScript actions	❌	❌	Commonly discarded

Three practical rules follow:

Sign last. Any signature applied before a merge or split is void afterwards. Assemble the document, then sign.
Flatten forms before merging. Two source files with a field named signature collide. Flattening converts fields to static page content and removes the ambiguity — at the cost of no longer being fillable.
Treat accessibility as a re-do. If the source PDFs were tagged for screen readers, verify the tag tree in the output; a merge that silently drops /StructTreeRoot produces a document that fails an accessibility audit even though it looks identical.

Doing It in the Browser

Client-side PDF assembly is genuinely practical: the page tree is a data structure, and rewriting it needs no rendering. A library such as pdf-lib parses the objects, copies pages, and serialises a new file entirely in browser memory.

import { PDFDocument } from "pdf-lib";

// MERGE: copy every page from each input into one output document.
async function mergePdfs(fileBuffers) {
 const out = await PDFDocument.create();
 for (const buf of fileBuffers) {
 const src = await PDFDocument.load(buf);
 const pages = await out.copyPages(src, src.getPageIndices());
 pages.forEach((p) => out.addPage(p));
 }
 return out.save(); // Uint8Array of the new PDF
}

// SPLIT: extract a 1-based inclusive page range.
async function extractRange(buf, from, to) {
 const src = await PDFDocument.load(buf);
 const out = await PDFDocument.create();
 const indices = Array.from({ length: to - from + 1 }, (_, k) => from - 1 + k);
 const pages = await out.copyPages(src, indices);
 pages.forEach((p) => out.addPage(p));
 return out.save();
}

copyPages performs the important work: it deep-copies each page’s referenced resources into the destination document and renumbers objects. Note what it does not do — carry over the outline tree, the form dictionary, or the structure tree. That omission is the source of most “my bookmarks vanished” reports, and it is a property of the operation rather than a bug in a particular tool.

Why local processing is the right default

A PDF you need to merge is usually a PDF you should not upload: a signed contract, a bank statement, a medical form, an ID scan. Uploading routes the document through a third party’s storage and logs, creating a retention question you cannot answer. Local assembly removes the question — with two honest limits:

Memory, not bandwidth, is the ceiling. A desktop browser handles a few hundred megabytes; a phone will fail much earlier on the same file.
Encrypted PDFs must be decrypted first. The page tree cannot be read through the encryption layer, so remove the open password in your reader before assembling.

Verifying the Output

Do not trust the page count alone. Three checks catch the failures that matter:

# 1. Structure: page count, encryption, version
pdfinfo output.pdf

# 2. Content: confirm removed text is actually gone
pdftotext output.pdf - | grep -i "confidential-term"

# 3. Size sanity: a split that removed 90% of pages should shrink accordingly
ls -l input.pdf output.pdf

Check 2 is the one people skip. If a page was removed because it held sensitive content, extracting text from the output is the only evidence that the content left with it. A result that is nearly the same size as the input, after dropping most of its pages, is a signal that objects were orphaned rather than removed.

Step-by-Step: Assembling a Document with Toolbox

Open the tool: visit the . For extracting pages, use the ; for reordering or rotating in place, the .
Remove passwords first if any input is encrypted — a protected file cannot have its page tree read.
Flatten fillable forms before merging documents that both contain form fields, to avoid field-name collisions.
Order the documents deliberately; metadata and, where preserved, the outline are typically inherited from the first input.
Export and verify: open the result, confirm the page count and page order, and if any page was dropped for confidentiality, extract the text and search for the term that mattered.
Sign or protect last, since signatures applied before assembly are invalidated by it.

Outcome: a correctly assembled document, with a deliberate decision recorded about bookmarks, forms, and signatures — and no confidential file handed to a third-party server on the way.

Related guides: · ·

FAQ

Frequently Asked Questions

Does deleting a page from a PDF actually remove its content from the file? ▼

Not necessarily. PDF supports incremental updates, where an editor appends a new cross-reference section instead of rewriting the file, so the removed page's objects can remain in the byte stream and be recoverable. Only a full rewrite drops orphaned objects, so verify that the output shrank as expected and re-extract text from the result before distributing it.

Why is my merged PDF larger than the sum of its inputs? ▼

Resources are duplicated rather than shared. Each source carries its own embedded font subsets, colour profiles, and image XObjects, and a naive merge copies all of them, so two files embedding the same font subset produce a doubled result. Some libraries deduplicate identical streams by hash; many do not. Recompressing or re-subsetting fonts recovers most of the size.

What is lost when a PDF is split into separate pages? ▼

Anything defined at document scope. Bookmarks pointing outside the extracted range become dangling and are usually dropped, internal links break, AcroForm hierarchies can lose shared fields, JavaScript and named destinations are often discarded, and digital signatures are invalidated because the signed byte range no longer exists. Page content, embedded fonts, and vector graphics survive.

Can a browser-based tool handle a large or encrypted PDF? ▼

Size is limited by available memory rather than an upload cap, so hundreds of megabytes usually work on a desktop while mobile browsers fail earlier. Encryption is a hard limit: the page tree cannot be read through the encryption layer, so remove the password in your PDF reader before merging or splitting.

Redacting Secrets and PII from AI Prompts: A Practical Client-Side DLP Method

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

QUICK ANSWER RFC SPECIFICATION SUMMARY

100% Client-Side

Prompt redaction removes secrets and personal data from text before it is sent to a language model. Detect structured items with anchored patterns — prefixed API keys such as sk- or ghp-, PEM private key blocks, JWTs, Luhn-valid card numbers, emails, phone numbers, and IP addresses — and add a Shannon entropy check to catch unprefixed high-randomness tokens. Replace each finding with a stable typed placeholder like EMAIL_1 rather than a blunt mask, so the text stays coherent and values can be substituted back locally. Run the whole pass client-side, because once the text is submitted the disclosure has already happened.

Difficulty: Intermediate Time: 7 Mins Privacy: 100% Client-Side RAM Standard: OWASP Top 10 for LLM Applications (2025)

Interactive Workbench LIVE

Redacting Secrets and PII from AI Prompts: A Practical Client-Side DLP Method

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

Air-Gapped Prompt DLP & Secret Redactor

Paste a log, stack trace, or prompt draft and review flagged secrets and personal data before anything is transmitted. Detection runs in local browser memory.

Open Prompt Redactor →

The Disclosure Happens at Submit Time

A developer debugging a failing integration pastes a stack trace into an AI assistant. The trace includes a request header. The header includes a bearer token. The token is valid for another 40 days.

Nothing malicious happened, no attacker was involved, and no configuration was wrong. The credential is nonetheless outside the trust boundary, and rotating it is now the only remedy. This class of leak is why Sensitive Information Disclosure is ranked LLM02 in the OWASP Top 10 for LLM Applications (2025 edition), alongside Prompt Injection at LLM01.

The important property of the failure is its timing: the exposure completes the moment the request is sent. No provider-side control, retention setting, or contract clause can retroactively un-send it. The only control that acts before the boundary is crossed is a client-side pass over the text.

What you get from this guide: a concrete inventory of what to strip, detection logic that catches the structured 80% reliably, a placeholder scheme that keeps prompts useful, and an honest statement of what automated redaction cannot do.

What Actually Needs to Leave

Class	Examples	Why it matters
Live credentials	API keys, bearer tokens, DB connection strings, PEM private keys, `.env` contents	Immediately exploitable; requires rotation once exposed
Direct identifiers	Names, emails, phone numbers, government IDs, addresses	Regulated personal data under GDPR, DPDP Act 2023, and similar regimes
Financial data	Card numbers, CVV, bank account and IFSC details, UPI handles	PCI DSS scope; card data should never transit an unrelated service
Health and biometric data	Diagnoses, prescriptions, patient identifiers	Special-category data in most regimes
Internal topology	Private hostnames, internal IP ranges, S3 bucket names, staging URLs	Reconnaissance value; maps your attack surface
Proprietary logic	Unreleased algorithms, pricing formulas, model weights, contract terms	Trade-secret status can depend on the measures you took to protect it

A useful heuristic: if you would not paste it into a public forum post, do not paste it into a prompt without redaction. The relevant question is not whether the provider is trustworthy; it is whether the data was ever necessary for the task. Most of the time a stack trace is just as debuggable with API_KEY_1 in place of the real token.

Detection Layer 1: Anchored Patterns

Structured secrets are detectable because vendors gave them fixed shapes — deliberately, to make scanning possible.

const PATTERNS = [
 // Credentials — prefixed vendor tokens
 { type: "OPENAI_KEY", re: /\bsk-[A-Za-z0-9_-]{20,}\b/g },
 { type: "ANTHROPIC_KEY",re: /\bsk-ant-[A-Za-z0-9_-]{20,}\b/g },
 { type: "GITHUB_PAT", re: /\b(gh[pousr]_[A-Za-z0-9]{36,})\b/g },
 { type: "AWS_ACCESS_KEY", re: /\b(?:AKIA|ASIA)[0-9A-Z]{16}\b/g },
 { type: "SLACK_TOKEN", re: /\bxox[abposr]-[A-Za-z0-9-]{10,}\b/g },
 { type: "STRIPE_KEY", re: /\b(?:sk|rk)_(?:live|test)_[A-Za-z0-9]{16,}\b/g },
 { type: "PRIVATE_KEY", re: /-----BEGIN (?:RSA |EC |OPENSSH )?PRIVATE KEY-----[\s\S]*?-----END[^-]*-----/g },
 { type: "JWT", re: /\beyJ[A-Za-z0-9_-]{8,}\.[A-Za-z0-9_-]{8,}\.[A-Za-z0-9_-]{8,}\b/g },
 { type: "CONN_STRING", re: /\b(?:postgres|postgresql|mysql|mongodb(?:\+srv)?|redis|amqp):\/\/[^\s"'<>]+/gi },

 // Personal data
 { type: "EMAIL", re: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b/g },
 { type: "IPV4", re: /\b(?:\d{1,3}\.){3}\d{1,3}\b/g },
 { type: "CARD", re: /\b(?:\d[ -]*?){13,19}\b/g }, // validate with Luhn before flagging
 { type: "UPI_VPA", re: /\b[\w.-]{2,}@(?:okhdfcbank|okicici|oksbi|okaxis|paytm|ybl|ibl|axl|upi)\b/gi },
];

Two refinements that decide whether the output is usable:

Validate card candidates with Luhn. Any 13-19 digit run matches the pattern, including order IDs and timestamps. The checksum removes most false positives:

function luhnValid(digits) {
 const d = digits.replace(/\D/g, "");
 if (d.length < 13 || d.length > 19) return false;
 let sum = 0, alt = false;
 for (let i = d.length - 1; i >= 0; i--) {
 let n = +d[i];
 if (alt) { n *= 2; if (n > 9) n -= 9; }
 sum += n; alt = !alt;
 }
 return sum % 10 === 0;
}

Do not blanket-flag IPv4. 127.0.0.1, 0.0.0.0, and documentation ranges are noise. Flag private ranges (10/8, 172.16/12, 192.168/16) and public addresses; skip loopback and unspecified.

Detection Layer 2: Entropy

Many real secrets carry no vendor prefix — a rotated internal token, a generated password, a session identifier. What they share is randomness. Shannon entropy over the character distribution separates them from ordinary words:

function shannonEntropy(s) {
 const freq = {};
 for (const ch of s) freq[ch] = (freq[ch] ?? 0) + 1;
 return -Object.values(freq).reduce((acc, n) => {
 const p = n / s.length;
 return acc + p * Math.log2(p);
 }, 0);
}

// Flag long alphanumeric runs whose per-character entropy is high.
function suspectHighEntropy(text, { minLen = 20, threshold = 3.5 } = {}) {
 return [...text.matchAll(/\b[A-Za-z0-9+/=_-]{20,}\b/g)]
 .filter((m) => shannonEntropy(m[0]) >= threshold)
 .map((m) => ({ value: m[0], index: m.index }));
}

Calibration in practice: English words sit near 2.5-3.2 bits per character; random Base64 sits near 4.5-6. A threshold around 3.5 with a 20-character minimum catches most unprefixed secrets while tolerating long identifiers. It will still flag Git commit SHAs and Base64 image fragments — acceptable for a review step, unacceptable for silent automatic replacement.

Replacement: Typed, Stable Placeholders

The instinct is to overwrite with asterisks. That is the wrong output, because it destroys the two properties that make the prompt worth sending.

Original : Charge card 4111111111111111 for alice@example.com, retry key sk-abc123XYZ...
Bad : Charge card **************** for *****************, retry key ***********
Better : Charge card CARD_1 for EMAIL_1, retry key API_KEY_1

Typed placeholders preserve type information (the model still knows it is reasoning about a card, an email, a key) and referential identity (the same original value maps to the same placeholder everywhere, so relationships across a long log stay intact). Rules that make this work:

Deterministic mapping per session. alice@example.com is always EMAIL_1; a second address becomes EMAIL_2.
Keep the map local. It is the sensitive artefact — never include it in the prompt, and clear it when done.
Preserve shape when shape is the question. For a format-validation task, 4111-11XX-XXXX-1111 is more useful than CARD_1; partial masking is the right choice only when structure is the subject.
Substitute back locally. When the model replies with send the receipt to EMAIL_1, restore the real value on your machine.

What This Method Cannot Do

Stating the limits is what separates a control from a comfort blanket.

Unstructured personal data survives. “The customer, a 34-year-old teacher in Pune who called about her cancelled order,” contains no pattern to match and is still identifying in combination.
Semantics are invisible to regex. A proprietary pricing formula written out in prose is a trade secret with no distinguishing byte pattern.
Aggregation re-identifies. Individually harmless fields — postcode, birth date, employer — combine into an identity.
Screenshots and attachments bypass text scanning entirely. Images carry text, and photographs carry .
The model’s own output can leak. LLM02 covers disclosure by the system as well as to it: a retrieval-augmented assistant can surface another tenant’s data through the answer path even when every prompt was clean.

Treat automated redaction as the last line before transmission, sitting under two stronger controls: not collecting the data into the prompt in the first place, and reviewing what you are about to send.

Step-by-Step: Sanitising a Prompt with Toolbox

Open the tool: visit the .
Paste the raw material — the stack trace, log excerpt, config file, or draft prompt, unedited.
Review every finding. Confirm the true positives and dismiss noise such as commit hashes; an automated pass is a proposal, not a verdict.
Read the remaining prose yourself for the class no scanner catches: named individuals, internal project names, described business logic.
Copy the redacted text into your model client, and keep the placeholder mapping on your machine only.
Rotate anything already exposed. If a live key was in the original text and that text was ever sent anywhere, redacting the copy does not help — revoke and reissue the credential.

Outcome: prompts that keep enough structure for the model to be useful while removing the material that would turn a debugging session into an incident report — and a clear separation between what automation caught and what still needs your eyes.

Related guides: · ·

FAQ

Frequently Asked Questions

Why does pasting a production log into an AI chat count as a data disclosure? ▼

Because the text leaves your trust boundary. Once submitted it sits in the provider's request path and may be retained under the plan's data policy, surface in abuse-review systems, or be visible to anyone with access to the workspace history. For regulated data that is a processing event regardless of what happens next, which is why OWASP ranks Sensitive Information Disclosure as LLM02 and why redaction belongs on the client.

Can regular expressions reliably find every secret in a prompt? ▼

No. Patterns handle structured tokens well — prefixed API keys, card numbers, emails, IPs, JWTs — but systematically miss unstructured disclosure such as a customer's name and city in a sentence, described proprietary logic, or a password with no distinctive format. Adding a Shannon entropy check on high-randomness strings improves recall, but automated redaction is a safety net under human review, not a guarantee.

Should I mask secrets or replace them with reversible placeholders? ▼

Use stable typed placeholders such as EMAIL_1 or API_KEY_2. Asterisk masking destroys the type information and the referential identity the model needs, and identical masks for different values make records indistinguishable. A deterministic mapping keeps the text coherent and lets you substitute real values back into the answer locally.

Does an enterprise agreement with zero data retention remove the need to redact? ▼

It lowers the risk but not the obligation. A retention promise covers the provider's storage, not your logs, proxy, browser history, or a screenshot in a ticket, and regimes such as the GDPR and India's Digital Personal Data Protection Act, 2023 regulate processing and transfer rather than storage alone. Minimising what you send is the control that survives contract changes and human error.

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.

SIP Maturity Formula Explained: Annuity Math, Step-Up SIPs, XIRR, and Taxation

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

Free In-Browser Tool TOOLBOX UTILITY

SIP Wealth & Compounding Calculator

Model monthly contributions, expected return, and tenure to see invested capital versus compounded gains year by year. Your financial figures never leave the browser.

Open SIP Calculator →

What a SIP Actually Is

A Systematic Investment Plan is not a product. It is a schedule: a fixed amount debited at a fixed interval and used to buy units of a mutual fund at that day’s net asset value. The fund is the product; the SIP is the discipline wrapped around it.

Two mechanical effects come out of that schedule:

Rupee cost averaging. A fixed rupee amount buys more units when the NAV is low and fewer when it is high, so the average cost per unit ends up below the average NAV over the period. This reduces the penalty for poor entry timing; it does not eliminate market risk.
Compounding over unequal holding periods. Your first instalment compounds for the full tenure. Your last instalment compounds for one month. The maturity value is the sum of many differently aged growth curves — which is exactly what the annuity formula computes in closed form.

What you get from this guide: the formula and its derivation, the step-up variant, an honest account of why projections and reality diverge, and the tax treatment that determines what you actually keep.

Deriving the Formula

Each instalment P invested at the start of a month grows for the remaining months at the periodic rate i. With n instalments:

M = P(1+i)^n + P(1+i)^(n-1) + … + P(1+i)^1

That is a geometric series with first term P(1+i) and ratio (1+i). Summing it gives the future value of an annuity due:

M = P × [ ((1 + i)^n − 1) / i ] × (1 + i)

Symbol	Meaning	Example
`M`	Maturity value	—
`P`	Monthly instalment	₹10,000
`i`	Periodic rate = annual % ÷ 12 ÷ 100	12% → 0.01
`n`	Number of instalments = years × 12	15 years → 180

Worked example

₹10,000 per month for 15 years at an expected 12% annual return:

i = 0.12 / 12 = 0.01
n = 15 × 12 = 180

(1.01)^180 ≈ 5.995802
((1.01)^180 − 1)/0.01 ≈ 499.5802
× (1.01) ≈ 504.5760

M ≈ 10,000 × 504.5760 ≈ ₹50,45,760
Invested = 10,000 × 180 = ₹18,00,000
Gain ≈ ₹32,45,760

Roughly 64% of the terminal value is growth rather than contribution — and that share rises steeply with tenure, which is the entire argument for starting early.

// Annuity-due future value. Handles i = 0 without dividing by zero.
function sipMaturity(monthly, annualRatePct, years) {
 const i = annualRatePct / 12 / 100;
 const n = Math.round(years * 12);
 if (i === 0) return monthly * n;
 return monthly * ((Math.pow(1 + i, n) - 1) / i) * (1 + i);
}

Tenure dominates everything

₹10,000 per month at 12%:

Tenure	Invested	Maturity	Gain	Gain as % of maturity
5 years	₹6,00,000	₹8,25,000	₹2,25,000	27%
10 years	₹12,00,000	₹23,23,000	₹11,23,000	48%
15 years	₹18,00,000	₹50,46,000	₹32,46,000	64%
20 years	₹24,00,000	₹99,91,000	₹75,91,000	76%
25 years	₹30,00,000	₹1,89,76,000	₹1,59,76,000	84%

Values rounded to the nearest thousand. Doubling the tenure from 10 to 20 years does not double the outcome — it roughly quadruples it.

Step-Up SIP: Matching Contributions to Income

A flat instalment held for 20 years ignores salary growth. A step-up (or top-up) SIP raises the instalment by a fixed percentage each year. The closed form is a sum over annual blocks:

M = Σ (k = 0 … Y−1) P × (1+g)^k × [ ((1+i)^12 − 1)/i ] × (1+i) × (1+i)^(12 × (Y−1−k))

where g is the annual step-up rate and Y the number of years. In code it is clearer as a loop:

function stepUpSipMaturity(monthly, annualRatePct, years, stepUpPct) {
 const i = annualRatePct / 12 / 100;
 const g = stepUpPct / 100;
 let value = 0;
 let instalment = monthly;

 for (let year = 0; year < years; year++) {
 for (let month = 0; month < 12; month++) {
 value = (value + instalment) * (1 + i); // invest at start, then grow
 }
 instalment *= 1 + g;
 }
 return value;
}

The effect of a 10% annual step-up, starting at ₹10,000 per month, 12% expected return:

Tenure	Flat SIP	10% step-up SIP	Difference
10 years	₹23,23,000	₹33,74,000	+45%
15 years	₹50,46,000	₹86,84,000	+72%
20 years	₹99,91,000	₹1,98,89,000	+99%

Values rounded to the nearest thousand and dependent on the assumed rate. The direction is the point: a step-up that tracks ordinary income growth changes the outcome more than most attempts to pick a better fund.

Why Reality Diverges from the Projection

The formula assumes one constant rate compounding smoothly. A market-linked fund does nothing of the sort. Four specific gaps:

Sequence of returns matters. Two funds with identical 12% averages produce different SIP outcomes depending on when the good and bad months fell, because each instalment bought a different number of units. A flat formula cannot capture this.
The expense ratio is a permanent drag. A 1.5% ratio versus 0.5% on the same underlying portfolio compounds into a large terminal difference over 20 years. Compare returns net of expenses.
Exit loads and redemption timing reduce the amount you actually receive; many equity funds levy a load on units redeemed within a year.
Inflation reduces purchasing power. ₹50 lakh in 15 years is not ₹50 lakh today. At 6% inflation, its real value is roughly ₹50,45,760 / 1.06^15 ≈ ₹21 lakh in today’s terms. Plan goals in real terms, not nominal.

Measure realised returns with XIRR, not CAGR

CAGR describes a single lump sum over one period. A SIP is many investments at many dates, so CAGR is not defined for it. XIRR solves for the rate r satisfying:

Σ CF_k / (1 + r)^(d_k / 365) = 0

over every dated cash flow CF_k — negative for instalments, positive for redemptions. Build a two-column table of dates and amounts in any spreadsheet and call XIRR(values, dates). That number, not the calculator’s assumed rate, is what your SIP actually earned.

Taxation of SIP Gains in India

Every instalment is a separate acquisition, and redemptions follow FIFO — the oldest units go first. One redemption can therefore contain both short-term and long-term units, taxed differently.

For equity-oriented funds (at least 65% in domestic equity), under the Finance (No. 2) Act, 2024 effective 23 July 2024:

Holding period	Classification	Rate
More than 12 months	Long-term (Section 112A)	12.5% on gains above ₹1.25 lakh per financial year
12 months or less	Short-term (Section 111A)	20%

The ₹1.25 lakh annual exemption applies to equity-oriented schemes including ELSS, and not to debt, gold, or international fund categories, which follow their own rules. Surcharge and cess apply on top as per your total income.

Planning consequence: redeeming a 20-year SIP in one transaction can push a large long-term gain into a single financial year, using the ₹1.25 lakh exemption only once. Staging redemptions across financial years, where the goal permits, uses the exemption more than once.

Tax rules change and depend on your circumstances. Confirm current provisions with a qualified tax adviser before acting.

Step-by-Step: Projecting a SIP with Toolbox

Open the tool: visit the .
Enter the monthly instalment and tenure in years — the two inputs you actually control.
Set a defensible expected return. Use a conservative figure and run a range (for example 10%, 12%, 14%) rather than a single optimistic number; the spread is the honest output.
Read invested capital against gains in the breakdown to see when compounding starts to dominate contributions, typically somewhere past year eight to ten at equity-like rates.
Deflate the result for inflation to state the goal in today’s purchasing power: divide the maturity value by (1 + inflation)^years.
Track the real outcome with XIRR once the SIP is running, using your actual dated cash flows — that is the only number that reflects what happened.

Outcome: a maturity projection you can defend as a scenario, an explicit inflation-adjusted target, and the correct measure to check performance against later.

Interactive Workbench LIVE

SIP Maturity Formula Explained: Annuity Math, Step-Up SIPs, XIRR, and Taxation

Open Fullscreen ↗

Model monthly contributions, expected return, and tenure to see invested capital versus compounded gains year by year.

Initializing Workbench...

100% Client-Side RAM Sandbox

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

Launch Fullscreen →

Related guides: · ·

FAQ

Frequently Asked Questions

What is the exact formula a SIP calculator uses? ▼

The future value of an annuity due: M = P × [((1 + i)^n − 1) / i] × (1 + i), where P is the monthly instalment, i is the annual expected return divided by 12 and by 100, and n is the number of instalments. The trailing (1 + i) reflects each instalment being invested at the start of its period; omitting it understates maturity by about one month of growth.

Why does my actual SIP return differ from the calculator's projection? ▼

A calculator assumes one constant rate compounding smoothly, while a fund returns something different every month and each instalment buys units at a different NAV, so the sequence of returns matters as well as the average. Expense ratios, exit loads, and redemption timing reduce the result further. Treat projections as planning scenarios.

What is the difference between CAGR and XIRR for a SIP? ▼

CAGR describes one lump sum over a single period and is undefined for instalments made at different dates. XIRR solves for the discount rate that makes the net present value of all dated cash flows zero, handling multiple contributions and partial withdrawals, which makes it the correct measure of realised SIP return.

How are SIP gains taxed in India? ▼

Each instalment is a separate purchase and redemptions are FIFO, so one redemption can hold both short-term and long-term units. For equity-oriented funds, units held over twelve months are long-term and taxed at 12.5% on gains above ₹1.25 lakh per financial year under Section 112A, while units held twelve months or less are taxed at 20% under Section 111A, per the Finance (No. 2) Act, 2024 effective 23 July 2024. Debt, gold, and international funds differ.

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

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

Interactive Workbench LIVE

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

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

URL Percent Encoder & Decoder

Switch between Encode and Decode tabs, paste any string, and get instant UTF-8-correct percent-encoding with one-click copy.

Open URL Encoder & Decoder →

Why URLs Need Encoding at All

A URL is not free-form text. It is a structured identifier in which certain characters carry meaning: ? starts the query, & separates parameters, # begins the fragment, / divides path segments.

The moment user data containing those characters is dropped into a URL, the structure collapses:

https://example.com/search?q=fish & chips#1
 ^ ^ ^
 | | └── parsed as a fragment
 | └──────── parsed as a parameter separator
 └─────────────── raw space, invalid in a URL

The server sees the parameter q with value fish , a second empty parameter named chips, and a fragment of 1. Percent-encoding solves this by giving every problematic character an unambiguous escaped form.

https://example.com/search?q=fish%20%26%20chips%231

The RFC 3986 Character Classes

Everything follows from three sets defined in RFC 3986.

Unreserved — safe everywhere, never needs encoding

A-Z a-z 0-9 - . _ ~

Section 2.3 states these are equivalent whether escaped or not. Encoding them is legal but pointless, and normalisers will decode them back.

Reserved — structurally meaningful, must be encoded inside data

Group	Characters	Role
gen-delims	`:` `/` `?` `#` `[` `]` `@`	Separate the major URL components
sub-delims	`!` `$` `&` `'` `(` `)` `*` `+` `,` `;` `=`	Delimiters inside a component

Everything else — must be encoded

Spaces, control characters, ", <, >, \, ^, `, {, |, }, and every non-ASCII character.

The Percent-Encoding Rule

character -> UTF-8 bytes -> %HH for each byte

Character	UTF-8 Bytes	Encoded
space	`20`	`%20`
`&`	`26`	`%26`
`/`	`2F`	`%2F`
`%`	`25`	`%25`
`é`	`C3 A9`	`%C3%A9`
`€`	`E2 82 AC`	`%E2%82%AC`
`🚀`	`F0 9F 9A 80`	`%F0%9F%9A%80`

RFC 3986 §2.1 says the hexadecimal digits should be uppercase; normalisers uppercase them, and %2f and %2F are equivalent on decode.

The Three JavaScript Functions

Function	Leaves Unencoded	Verdict
`encodeURIComponent()`	`A-Z a-z 0-9 - _ . ! ~ * ' ( )`	Use this for values
`encodeURI()`	The above plus `; / ? : @ & = + $ , #`	Only for a whole URL
`escape()`	Legacy, emits non-standard `%uXXXX`	Never use — deprecated in Annex B

The Decision Rule

Encoding a piece of data? encodeURIComponent. Encoding an already-assembled URL? encodeURI.

const query = 'fish & chips';
const redirect = 'https://example.com/next?id=7';

// Correct — each value encoded independently.
const url =
 `https://example.com/search?q=${encodeURIComponent(query)}` +
 `&next=${encodeURIComponent(redirect)}`;

// Wrong — encodeURI leaves & and = intact, so the nested URL's
// own parameters merge into the outer query string.
const broken = encodeURI(`https://example.com/search?next=${redirect}`);

That second case — a URL nested inside a query parameter — is the classic failure. encodeURI preserves ? and & because it assumes they are your delimiters, and an OAuth redirect_uri or a ?next= parameter promptly falls apart.

Where `encodeURIComponent` Diverges from RFC 3986

encodeURIComponent leaves !, ', (, ), and * unescaped, although RFC 3986 classifies them as sub-delims rather than unreserved. Most servers cope, but strict parsers and signature-verifying APIs — AWS Signature V4 and OAuth 1.0a among them — do not. For strict compliance:

function rfc3986(str) {
 return encodeURIComponent(str).replace(
 /[!'()*]/g,
 (c) => '%' + c.charCodeAt(0).toString(16).toUpperCase()
 );
}

`%20` or `+`: Two Specifications, One Space

This trips up experienced engineers because both are correct — in different contexts.

Context	Space Becomes	Governing Specification
Path segment	`%20`	RFC 3986
Fragment	`%20`	RFC 3986
`encodeURIComponent()` output	`%20`	ECMA-262
HTML form `GET` submission	`+`	`application/x-www-form-urlencoded`
`URLSearchParams` serialisation	`+`	WHATWG URL Standard

const p = new URLSearchParams();
p.set('q', 'fish & chips');
p.toString(); // "q=fish+%26+chips"

encodeURIComponent('fish & chips'); // "fish%20%26%20chips"

Both round-trip correctly through a form-encoding parser. But a generic RFC 3986 parser reading a path decodes + as a literal plus sign. The practical consequences:

A + in a path segment is a plus, not a space. /files/my+file.txt refers to a file whose name contains a plus.
Encode a literal plus in form data as %2B. Otherwise user+tag@example.com arrives as user tag@example.com — the reason so many sites mangle plus-addressed email.
Pick one serialiser per codebase. Mixing URLSearchParams with hand-built strings produces query strings that decode inconsistently.

Failure Modes Worth Recognising

1. Double Encoding

Percent-encoding is not idempotent, because % is itself an encodable character.

"a b" -> encode -> "a%20b" -> encode again -> "a%2520b"

The server decodes once and hands your application the literal string a%20b. Symptom: values that visibly contain %20, %3D, or %26 after parsing. Cause: a value encoded at construction time and encoded again by a helper, a proxy, or a template. Encode exactly once, as late as possible.

2. Encoded Slashes Rejected by the Server

%2F inside a path segment is legal, but Apache HTTP Server defaults to AllowEncodedSlashes Off and returns 404 for such requests. Never place a value that might contain / into a path segment — put it in the query string instead.

3. `URIError: URI malformed`

decodeURIComponent throws on a truncated or invalid escape such as %E0%A4 or %ZZ. Any decode of untrusted input needs a guard:

function safeDecode(value) {
 try {
 return decodeURIComponent(value);
 } catch {
 return value; // Malformed input — return it untouched rather than crashing.
 }
}

4. Non-ASCII Hostnames Are Not Percent-Encoded

Percent-encoding applies to the path, query, and fragment. Internationalised domain names use Punycode (RFC 3492/5891) instead: münchen.de becomes xn--mnchen-3ya.de. Encoding a hostname with encodeURIComponent produces an unresolvable name.

5. Encoded Data in Logs Is Still Sensitive

Percent-encoding is not obfuscation. Anything placed in a query string lands in server access logs, proxy caches, Referer headers, and browser history. Tokens and secrets belong in headers or a request body — a point worth remembering when .

When to Reach for Base64 Instead

Percent-encoding is designed for text that is mostly URL-safe already. Encoding binary data with it is wasteful — every byte becomes three characters.

For binary payloads inside a URL, use base64url (RFC 4648 §5), which substitutes - and _ for + and / and drops padding, producing a string made entirely of unreserved characters. This is exactly what JWT segments use. The covers the mechanics, and the shows base64url in production.

Step-by-Step: Encoding with Toolbox

Open the tool: visit the .
Choose a tab — Encode to convert raw text into percent-encoded form, Decode to reverse it.
Paste the value, not the whole URL. Encode one query parameter value or one path segment at a time, then assemble the URL yourself.
Read the output — the encoder applies the browser’s native encodeURIComponent, so UTF-8 multi-byte characters convert correctly.
Copy the result and drop it into your request, config file, or test case.
Diagnose double encoding by pasting a suspect value into the Decode tab. If one pass still leaves % sequences behind, the value was encoded twice upstream.

Encoding runs entirely on your device through the browser’s own URL functions, so tokens, search terms, and customer identifiers in the strings you are debugging are never transmitted.

FAQ

Frequently Asked Questions

What is the difference between encodeURI and encodeURIComponent? ▼

encodeURI is for a complete URL and deliberately leaves the reserved structural characters ; / ? : @ & = + $ , # untouched so the URL keeps working. encodeURIComponent is for a single piece of data being placed inside a URL, such as one query parameter value, and escapes those reserved characters as well. Use encodeURIComponent for values and encodeURI only when handling an entire URL string.

Why does a space sometimes become %20 and sometimes a plus sign? ▼

Percent-encoding under RFC 3986 always represents a space as %20. The plus sign comes from a different and older specification, application/x-www-form-urlencoded, which HTML forms and the URLSearchParams API use for query strings. Both forms are decoded as a space by a form-encoding parser, but a generic RFC 3986 parser treats a literal plus as a plus, which is why the same string can decode differently on two servers.

Which characters never need to be percent-encoded? ▼

RFC 3986 section 2.3 defines the unreserved set as the ASCII letters A to Z and a to z, the digits 0 to 9, and the four symbols hyphen, period, underscore, and tilde. These characters are equivalent whether encoded or not, so encoding them adds length without changing meaning. Every other character is either reserved, meaning it has structural significance, or must be encoded.

Why did my URL break after being encoded twice? ▼

Percent-encoding is not idempotent. The percent sign is itself a character that must be encoded as %25, so running an already-encoded string through the encoder again turns %20 into %2520. The receiving server decodes only once and reads a literal %20 in the value. Encode exactly once, at the point where a raw value is inserted into a URL, and never on a string that already contains percent-escapes.

How are non-ASCII characters such as accented letters encoded? ▼

RFC 3986 section 2.5 specifies that a character is first converted to its UTF-8 byte sequence, then each byte is percent-encoded individually. The letter e-acute becomes the two bytes 0xC3 0xA9, which encode as %C3%A9. This is also why the legacy JavaScript escape function must never be used: it emits a non-standard %uXXXX form that is not valid percent-encoding.

X.509 Certificate Anatomy: SAN, Chain Validation, and the 200-Day Lifetime Era

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

Interactive Workbench LIVE

X.509 Certificate Anatomy: SAN, Chain Validation, and the 200-Day Lifetime Era

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

SSL / X.509 Certificate Inspector

Paste a PEM certificate or load a DER file to read every field and extension locally. Internal hostnames in SAN entries stay on your machine.

Open Certificate Inspector →

What a Certificate Actually Asserts

A TLS certificate makes one claim: this public key belongs to these names, and a certificate authority is willing to sign that statement until this date. Everything else — the fields, the extensions, the chain — exists to make that claim verifiable by a client that has never seen your server before.

X.509 is defined by RFC 5280 for the internet PKI profile, with additional rules imposed by the CA/Browser Forum Baseline Requirements, which browsers enforce. When the RFC and the Baseline Requirements disagree, browsers follow the Baseline Requirements — which is precisely why Common Name matching is dead in practice while still present in the RFC’s data model.

What you get from this guide: the ability to read a certificate dump line by line, diagnose the four errors that account for most TLS incidents, and plan renewal automation against the shortening lifetime schedule.

The Three-Part Structure

Certificate ::= SEQUENCE {
 tbsCertificate TBSCertificate, -- everything that is signed
 signatureAlgorithm AlgorithmIdentifier,
 signatureValue BIT STRING -- the CA's signature over tbsCertificate
}

The CA signs the DER encoding of tbsCertificate. Change one byte of a name, a date, or an extension and the signature no longer verifies — which is why certificates cannot be edited, only reissued.

Inside `tbsCertificate`

Field	Meaning	What to check
`version`	1, 2, or 3 (`v3` = value `2`)	Anything but v3 is obsolete
`serialNumber`	CA-unique identifier	Must be ≥ 64 bits of CSPRNG entropy per Baseline Requirements
`signature`	Algorithm the CA used	`sha256WithRSAEncryption` or `ecdsa-with-SHA256`; SHA-1 signatures are rejected
`issuer`	Distinguished Name of the CA	Must match the intermediate’s `subject` exactly
`validity`	`notBefore` / `notAfter`	Times are UTC; `UTCTime` before 2050, `GeneralizedTime` after
`subject`	Distinguished Name of the holder	Informational for TLS host matching
`subjectPublicKeyInfo`	Algorithm + public key	Same SPKI structure as a
`extensions`	v3 extension list	Where all the operational meaning lives

The v3 Extensions That Decide Everything

Extension	Critical?	Role
subjectAltName (SAN)	No	The list of names the certificate covers: `DNS`, `IP`, `email`, `URI`
basicConstraints	Yes	`CA:TRUE` marks a CA certificate; `pathLenConstraint` caps chain depth
keyUsage	Yes	`digitalSignature`, `keyEncipherment`, `keyCertSign` …
extendedKeyUsage (EKU)	Often	`serverAuth`, `clientAuth`, `codeSigning` — a `serverAuth`-only cert cannot authenticate a client
authorityInfoAccess (AIA)	No	URLs for the issuer certificate and the OCSP responder
cRLDistributionPoints	No	Where to fetch the CRL
subjectKeyIdentifier / authorityKeyIdentifier	No	Hints that let a verifier pick the right issuer quickly
signedCertificateTimestamp (SCT)	No	Certificate Transparency proofs; Chrome requires them for public trust

Common Name is not identity

CN=example.com inside the subject DN is a legacy artefact. RFC 6125 deprecated CN-based host matching, and the Baseline Requirements require every covered DNS name to be present in SAN. Modern browsers validate against SAN entries only.

X509v3 Subject Alternative Name:
 DNS:example.com, DNS:www.example.com, DNS:*.api.example.com

Wildcard rules that surprise people:

*.example.com matches api.example.com but not example.com itself, and not a.b.example.com. One label, one level.
The wildcard must be the leftmost label. api.*.example.com is invalid.
A certificate for both apex and subdomains needs both example.com and *.example.com in SAN.

How Chain Validation Works

A client performs path construction followed by path validation (RFC 5280 § 6):

Start at the leaf. Read its issuer DN.
Find a candidate issuer whose subject DN matches, from the certificates the server sent or from the local trust store; authorityKeyIdentifier disambiguates when several match.
Verify the signature on the child using the candidate’s public key.
Check the candidate is allowed to be a CA: basicConstraints must say CA:TRUE, keyUsage must include keyCertSign, and pathLenConstraint must not be exceeded.
Repeat until reaching a certificate present in the trust store.
Then validate the leaf’s own properties: current time inside the validity window, hostname against SAN, EKU includes serverAuth, and revocation status.

[ leaf: example.com ] --issued by--> [ intermediate CA ] --issued by--> [ root CA ]
 sent by server sent by server in OS/browser trust store

The server’s job: send the leaf and every intermediate, leaf first. Do not send the root. A client that already trusts the root ignores your copy; a client that does not trust it will not start trusting it because you attached it.

# Show the chain a server actually presents
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Verify a local chain offline
openssl verify -untrusted intermediate.pem leaf.pem

Revocation: OCSP, CRL, and What Browsers Really Do

Revocation is the weakest link in web PKI. Three mechanisms coexist:

Mechanism	How it works	Reality
CRL	Client downloads a signed list of revoked serials	Large files; poor latency; browsers largely stopped live checks
OCSP	Client queries the responder for one serial	Privacy leak (the CA learns browsing) and a soft-fail on timeout
OCSP stapling	The server fetches a signed OCSP response and attaches it in the handshake	The deployable answer; enable it
Pushed lists	Browser ships aggregated revocation data it compiled	What major browsers increasingly rely on in practice

The structural weakness is soft-fail: if a client cannot reach the responder, it proceeds rather than break the site — so an attacker who can block the OCSP query can also suppress a revocation. This is a large part of why the industry chose to shrink certificate lifetimes instead: a 47-day certificate limits the damage window without depending on revocation working at all.

The Shrinking Lifetime Schedule

CA/Browser Forum ballot SC-081v3, approved in April 2025, sets a phased reduction in the maximum validity of publicly trusted TLS certificates:

Effective date	Maximum validity
Before 15 March 2026	398 days
15 March 2026	200 days
15 March 2027	100 days
15 March 2029	47 days

Many CAs issue at 199 days to stay clear of the boundary. Domain validation data reuse periods shrink on a parallel schedule.

Operational consequences to plan for now:

Automate with ACME. At 47 days, renewal must be a cron-grade process. Manual calendar reminders will fail.
Instrument expiry, don’t trust it. Alert at 30 days and 7 days remaining, measured from the live certificate the server presents — not from your issuance records.
Audit the non-web endpoints. Load balancers, mail gateways, API gateways, mutual-TLS clients, and appliances with hand-uploaded certificates are where 47-day renewal breaks first.
Keep intermediates fresh. A stale pinned intermediate bundle survives a 398-day cadence and fails under a 47-day one.

The Four Errors Worth Recognising Instantly

Symptom	Root cause	Fix
`NET::ERR_CERT_COMMON_NAME_INVALID`	Hostname absent from SAN	Reissue with the name in SAN; CN alone is ignored
`unable to get local issuer certificate`	Intermediate not served	Append the intermediate to the chain file, leaf first
`NET::ERR_CERT_DATE_INVALID`	Expired, or server clock wrong	Renew; also verify NTP on the server
`NET::ERR_CERT_AUTHORITY_INVALID`	Self-signed or private CA not trusted	Install the root in the client trust store, or use a public CA

A fast triage rule: if openssl verify -untrusted succeeds locally but browsers fail, the certificate is fine and the server chain configuration is wrong.

Step-by-Step: Auditing a Certificate with Toolbox

Obtain the certificate: export it from your CA dashboard, or capture it live with openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509.
Open the tool: visit the and paste the PEM block or load the DER file.
Read the SAN list first — this is what browsers match. Confirm every hostname you serve is present, including the apex if you serve it.
Check notAfter against the current lifetime cap. Under the 200-day regime, a certificate issued with a longer window is a red flag about the issuance path.
Confirm key and signature strength: RSA ≥ 2048 bits or an approved curve, and a SHA-256-or-better signature algorithm.
Verify the chain separately, since a single certificate cannot prove its own path: openssl verify -untrusted intermediate.pem leaf.pem.

Outcome: you can tell within a minute whether an incident is a naming problem, a chain problem, an expiry problem, or a trust-store problem — and you inspect internal hostnames without publishing them to a third-party service.

Related guides: · ·

FAQ

Frequently Asked Questions

Why do browsers ignore the Common Name in a certificate? ▼

RFC 6125 deprecated Common Name matching for host identity, and the CA/Browser Forum Baseline Requirements require every covered DNS name to appear in the Subject Alternative Name extension. Chrome, Firefox, and Safari match hostnames against SAN entries only, so a certificate carrying the hostname only in CN fails with a name mismatch.

What is the difference between a certificate chain and a certificate bundle? ▼

A chain is the ordered path from the leaf through intermediates to a root the client already trusts; a bundle is the file holding them. Servers must send the leaf plus all intermediates in order and should omit the root. Missing intermediates cause a site to work in one client and fail in another, because some clients can fetch the issuer via Authority Information Access while others cannot.

How long can a TLS certificate be valid in 2026? ▼

Under CA/Browser Forum ballot SC-081v3, the maximum validity for publicly trusted TLS certificates fell from 398 days to 200 days on 15 March 2026, drops to 100 days on 15 March 2027, and to 47 days on 15 March 2029. Many CAs issue at 199 days to avoid boundary rejections, which makes ACME automation mandatory rather than optional.

Can I inspect a certificate safely without uploading it anywhere? ▼

Yes. A server certificate holds only public data, but internal hostnames and staging names in SAN entries are useful reconnaissance for an attacker. A client-side inspector parses the ASN.1 DER structure in browser memory, so nothing is transmitted, logged, or retained elsewhere.

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.

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.

Cron Syntax & Expression Architecture: The Complete Guide to Scheduling Jobs

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

Free In-Browser Tool TOOLBOX UTILITY

Cron Schedule Builder

Build, parse, and validate cron schedules with instant human-readable English descriptions and live execution timeline preview.

Open Cron Builder & Schedule Tester →

What Is Cron and Why Does Syntax Precision Matter?

Derived from the Greek word Chronos (time), cron is the universal time-based job scheduler found in Unix-like operating systems, cloud task runners (AWS EventBridge, Google Cloud Scheduler), and backend background queues (Celery, BullMQ, Sidekiq).

A misconfigured cron expression in production can lead to severe consequences:

Database backup scripts running every minute instead of every night at midnight, causing CPU exhaustion.
Billing webhooks executing twice during a Daylight Saving Time autumn rollback.
Data retention cleanups failing to execute because of contradictory day-of-month and day-of-week constraints.

Understanding the underlying grammar of cron expressions enables engineers to write deterministic, resilient background job schedules.

The 5-Field UNIX Cron Anatomy

Standard POSIX / Vixie cron expressions are composed of five distinct fields separated by white space:

 ┌───────────── Minute (0 - 59)
 │ ┌───────────── Hour (0 - 23, 24-hour clock)
 │ │ ┌───────────── Day of the Month (1 - 31)
 │ │ │ ┌───────────── Month of the Year (1 - 12 or JAN - DEC)
 │ │ │ │ ┌───────────── Day of the Week (0 - 6 or SUN - SAT)
 │ │ │ │ │
 * * * * *

Detailed Field Range Specifications

Field Position	Field Name	Allowed Values	Allowed Special Characters
1	Minute	`0 - 59`	`*` `,` `-` `/`
2	Hour	`0 - 23`	`*` `,` `-` `/`
3	Day of Month	`1 - 31`	`*` `,` `-` `/`
4	Month	`1 - 12` or `JAN - DEC`	`*` `,` `-` `/`
5	Day of Week	`0 - 6` (0 = Sunday, 6 = Saturday)	`*` `,` `-` `/`

Note on Sunday representation: In many modern implementations (including Vixie Cron, crontab on Ubuntu, and macOS), both 0 and 7 are accepted as Sunday for usability.

Special Operators Explained

Cron expressions derive their expressive power from five core syntax operators:

1. Asterisk (`*`) — The Wildcard

Matches every valid unit within the field’s permissible range.

* * * * *: Runs at the beginning of every minute of every hour, day, and month.
0 * * * *: Runs at minute 0 of every hour (i.e. once every hour on the hour).

2. Comma (`,`) — Value Lists

Defines an explicit enumeration of discrete values.

0 9,12,18 * * *: Triggers at 9:00 AM, 12:00 PM, and 6:00 PM every day.
0 0 * * 1,3,5: Runs at midnight on Mondays, Wednesdays, and Fridays.

3. Hyphen (`-`) — Value Ranges

Specifies a continuous, inclusive interval between two bounds.

0 9-17 * * *: Runs at minute 0 of every hour between 9:00 AM and 5:00 PM inclusive.
0 0 1-7 * *: Runs at midnight on the first seven days of every month.

4. Slash (`/`) — Step Values

Specifies step increments through a range. When preceded by an asterisk (*/n), it means “every n units starting from the minimum bound”.

*/15 * * * *: Runs at minutes 0, 15, 30, and 45 of every hour.
0 0/2 * * *: Runs every 2 hours (00:00, 02:00, 04:00, 06:00, …).
10-50/10 * * * *: Runs between minutes 10 and 50 in 10-minute steps (10, 20, 30, 40, 50).

5-Field Standard vs 6-Field Extended (Quartz / AWS)

While POSIX systems use the 5-field format, several popular enterprise engines (Java Quartz Scheduler, AWS CloudWatch / EventBridge, Spring Framework @Scheduled) utilize 6-field or 7-field formats:

Architecture Dimension	5-Field UNIX (POSIX / crontab)	6-Field Quartz / AWS EventBridge
Seconds Precision	❌ No (Minute is lowest granularity)	✅ Yes (Field 1 is Seconds `0-59`)
Year Specification	❌ Not supported	✅ Supported as optional 7th field (`1970-2099`)
Question Mark (`?`) Operator	❌ Throws syntax error	✅ Mandatory when specifying Day of Month or Week
`L` (Last) and `W` (Weekday)	❌ Rarely supported	✅ Fully supported (`L` = last day, `15W` = nearest weekday)
Primary Platforms	Linux `crontab`, Node.js `node-cron`, Python `Celery`	AWS EventBridge, Spring Boot, Quartz Java, Kubernetes CronJobs

Example: Quartz / AWS Syntax

In AWS EventBridge, a schedule running at 10:15 AM every weekday requires 6 fields and the ? character:

cron(0 15 10 ? * MON-FRI *)

10 Common Production Cron Recipes

Here are production-tested recipes ready to deploy for common infrastructure patterns:

Operational Objective	Standard Cron Expression	English Meaning
Health Check Heartbeat	`/5 * * *`	Every 5 minutes
Hourly Log Rotation	`0 * * * *`	Once an hour on the hour (:00)
Nightly Database Backup	`0 2 * * *`	Every day at 02:00 AM
Weekday Business Hours Task	`0 9 * * 1-5`	Monday through Friday at 09:00 AM
Weekly Maintenance Window	`0 3 * * 0`	Every Sunday at 03:00 AM
Monthly Invoice Generation	`0 0 1 * *`	1st of every month at midnight (00:00)
Quarterly Audit Report	`0 0 1 1,4,7,10 *`	1st of Jan, Apr, Jul, Oct at midnight
Twice-Daily Cache Warmup	`0 6,18 * * *`	Every day at 06:00 AM and 06:00 PM
End of Month Reconciliation	`0 23 28-31 * *`	Nightly from 28th-31st (pair with bash check)
Yearly Archival	`0 0 1 1 *`	January 1st at midnight

Critical Pitfalls & Production Best Practices

1. The Daylight Saving Time (DST) Trap

When a server is configured to a local timezone observing Daylight Saving Time:

Spring Forward (+1 hr): At 2:00 AM, the clock jumps directly to 3:00 AM. Any job scheduled for 0 2 * * * is completely skipped.
Fall Back (-1 hr): At 2:00 AM, the clock rewinds to 1:00 AM. Any job scheduled between 1:00 AM and 2:00 AM runs twice.

Solution: Always set the system timezone of worker servers and container clusters to UTC (tzdata: Etc/UTC).

2. The “Thundering Herd” Problem

If 50 different microservices schedule heavy batch jobs at exactly 0 0 * * * (midnight), database IOPS and CPU utilization will spike dramatically.

Solution: Stagger cron schedules with jitter. Run service A at 17 2 * * *, service B at 34 2 * * *, and service C at 49 2 * * *.

3. Day of Month AND Day of Week Interaction

In POSIX cron, if you specify both:

0 0 15 * 1

The job does not execute only when the 15th happens to be a Monday. It executes whenever the day is the 15th OR whenever the day is a Monday.

Step-by-Step: Generating Cron Schedules with Toolbox

Open the Tool: Visit the .
Select Frequency: Use the interactive visual controls to choose between Minute, Hourly, Daily, Weekly, Monthly, or Custom intervals.
Inspect Real-Time Translation: The engine instantly renders a plain-English translation of your schedule (e.g. “At 02:30 AM on day 1 of the month”).
Preview Next 5 Execution Dates: Verify the exact upcoming UTC and local timestamps to ensure no scheduling surprises occur.
Copy Expression: Click Copy Expression to paste the POSIX-compliant string directly into your crontab, Dockerfile, or infrastructure code.

Interactive Workbench LIVE

Cron Syntax & Expression Architecture: The Complete Guide to Scheduling Jobs

Open Fullscreen ↗

Build, parse, and validate cron schedules with instant human-readable English descriptions and live execution timeline preview.

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

What is the standard order of fields in a 5-field cron expression? ▼

The 5 standard UNIX cron fields from left to right are: 1. Minute (0-59), 2. Hour (0-23), 3. Day of the Month (1-31), 4. Month of the Year (1-12 or JAN-DEC), and 5. Day of the Week (0-6 or SUN-SAT, where 0 and 7 usually represent Sunday).

What is the difference between * and */5 in cron syntax? ▼

An asterisk (*) matches every possible value in that field (e.g. * in the minute field means run every minute). A step value with a slash (*/5) matches every nth interval starting from the field's minimum (e.g. */5 in the minute field triggers at minutes 0, 5, 10, 15, ..., 55).

How does Daylight Saving Time (DST) affect scheduled cron jobs? ▼

If your server timezone observes DST, schedules running during the transition hour can either be skipped entirely (when clocks spring forward by 1 hour) or execute twice (when clocks fall back by 1 hour). For mission-critical background jobs and batch billing, servers and cron schedulers should always be configured to UTC.

Can I specify both Day of Month and Day of Week simultaneously? ▼

In standard UNIX cron (Vixie Cron), specifying non-wildcard values in both the Day of Month and Day of Week fields creates an OR condition rather than an AND condition. The job triggers whenever EITHER condition matches. In Quartz/AWS cron, one of these fields must be set to '?' to avoid ambiguous scheduling.

How to Calculate Work Hours, Overtime, and Break Deductions (Accurately)

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

Free In-Browser Tool TOOLBOX UTILITY

Timesheet & Work Hours Calculator

Calculate weekly timesheet hours, unpaid meal breaks, overtime multipliers, and gross pay with instant CSV export.

Open Timesheet & Work Hours Calculator →

Why Accurate Work Hours and Payroll Calculation Matters

Tracking employee shift hours and computing gross wages sounds straightforward, yet payroll discrepancies remain one of the leading causes of employer wage-and-hour compliance audits and worker grievances.

The primary root causes of payroll errors stem from:

Confusing clock minutes with decimal hours (e.g. calculating $8\text{ hrs } 45\text{ mins} \times \$20$ as $8.45 \times $20$ instead of $8.75 \times $20$).
Incorrectly tracking unpaid meal breaks versus paid rest breaks.
Misapplying daily versus weekly overtime thresholds across state and federal jurisdictions.

Understanding the mathematical standards behind time arithmetic ensures transparent, compliant, and friction-free payroll processing.

The Sexagesimal to Decimal Conversion Trap

Human clocks operate in base-60 (sexagesimal), where an hour is divided into 60 minutes. Payroll accounting systems operate in base-10 (decimal).

$$\text{Decimal Hours} = \text{Whole Hours} + \left( \frac{\text{Minutes}}{60} \right)$$

Minute-to-Decimal Reference Table

Clock Minutes	Division Formula	Decimal Fraction	Real-World Impact (at $30/hr)
15 Minutes	$15 / 60$	0.25	$7.50
30 Minutes	$30 / 60$	0.50	$15.00
45 Minutes	$45 / 60$	0.75	$22.50
10 Minutes	$10 / 60$	0.17	$5.00
20 Minutes	$20 / 60$	0.33	$10.00
40 Minutes	$40 / 60$	0.67	$20.00
50 Minutes	$50 / 60$	0.83	$25.00

⚠️ Common Blunder: An employee works 8 hours and 30 minutes. If entered into an accounting spreadsheet as 8.30 hours $\times \$25/\text{hr}$, the result is $$207.50$. The actual calculation is $8.50 \times $25 = $212.50$. The employee loses $$5.00$ on a single shift!

Calculating Net Shift Hours with Break Deductions

When employees work full shifts, labor laws typically require meal breaks. In most legal jurisdictions:

Rest Breaks (5–20 minutes): Count as paid compensable work time under labor guidelines.
Meal Breaks (30–60 minutes): Unpaid, provided the employee is fully relieved of all work duties.

The Shift Calculation Algorithm

$$\text{Gross Shift Minutes} = \text{End Time (Minutes from Midnight)} - \text{Start Time (Minutes from Midnight)}$$$$\text{Net Payable Minutes} = \text{Gross Shift Minutes} - \text{Unpaid Meal Break Minutes}$$$$\text{Net Decimal Hours} = \frac{\text{Net Payable Minutes}}{60}$$

Example Shift Across Midnight

Suppose a night-shift employee starts work at 9:30 PM (21:30) and finishes at 6:00 AM (06:00) with a 45-minute unpaid lunch break:

Convert start time to minutes: $21 \times 60 + 30 = 1,290 \text{ minutes}$.
Convert end time to next day minutes: $(24 + 6) \times 60 = 1,800 \text{ minutes}$.
Elapsed gross duration: $1,800 - 1,290 = 510 \text{ minutes}$ (8.5 hours).
Subtract 45-minute break: $510 - 45 = 465 \text{ minutes}$.
Convert to decimal hours: $\frac{465}{60} = \mathbf{7.75 \text{ hours}}$.

Overtime Models: Daily vs Weekly Thresholds

Depending on geographic location and contractual agreements, overtime is computed under one of two primary frameworks:

Overtime Dimension	Weekly Overtime (Federal FLSA Standard)	Daily Overtime (e.g. California Labor Code)
Trigger Threshold	Greater than 40 regular hours in a workweek	Greater than 8 hours worked in a single calendar day
Rate Multiplier (1.5x)	Hours > 40 per week paid at $1.5 \times \text{Base Rate}$	Hours between 8.0 and 12.0 in a single day
Double Time (2.0x)	Not federally mandated	Hours exceeding 12.0 in a single day; or all hours on 7th consecutive day
Typical Jurisdictions	46 US States, UK, Canada, Australia	California, Nevada, Alaska, Colorado

The Gross Earnings Formula

$$\text{Gross Pay} = (\text{Regular Hours} \times \text{Rate}) + (\text{Overtime Hours} \times \text{Rate} \times 1.5) + (\text{Double Time Hours} \times \text{Rate} \times 2.0)$$

The FLSA 7-Minute / 15-Minute Rounding Standard

Under US Fair Labor Standards Act (29 CFR § 785.48(b)), businesses that track employee punch-clocks may round time to the nearest 15-minute interval:

Clock Minutes Passed Quarter-Hour	Rounding Rule	Rounded Time Value
:01 to :07 minutes	Round down	Prev. :00 (0.00 hrs)
:08 to :14 minutes	Round up	Next :15 (0.25 hrs)
:16 to :22 minutes	Round down	Prev. :15 (0.25 hrs)
:23 to :29 minutes	Round up	Next :30 (0.50 hrs)
:31 to :37 minutes	Round down	Prev. :30 (0.50 hrs)
:38 to :44 minutes	Round up	Next :45 (0.75 hrs)
:46 to :52 minutes	Round down	Prev. :45 (0.75 hrs)
:53 to :59 minutes	Round up	Next :00 (1.00 hrs)

⚖️ Legal Caveat: The rounding practice must be applied symmetrically to clock-ins and clock-outs. It cannot be configured to systematically round clock-ins forward and clock-outs backward, which illegally deprives workers of wages.

Step-by-Step: Using the Toolbox Timesheet Calculator

Open the Calculator: Navigate to the .
Configure Hourly Wage & OT Rules: Set your base hourly rate and specify your daily overtime limit (e.g., 8 hours) or weekly threshold.
Log Daily Hours: Input Monday through Sunday start times, end times, and meal break deductions.
Instant Calculation: The engine dynamically totals regular hours, overtime hours, and gross pay in real-time.
One-Click CSV Export: Download a structured payroll timesheet CSV ready for import into QuickBooks, Gusto, ADP, or Excel.

Interactive Workbench LIVE

Calculate Work Hours, Overtime, and Break Deductions (Accurately)

Open Fullscreen ↗

Calculate weekly timesheet hours, unpaid meal breaks, overtime multipliers, and gross pay with instant CSV export.

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 8 hours and 30 minutes equal to 8.5 decimal hours instead of 8.3? ▼

Time uses a sexagesimal (base-60) system, whereas decimal arithmetic uses base-10. To convert minutes into decimal fractions of an hour, divide the minute value by 60. For 30 minutes: 30 / 60 = 0.50. Entering 8.3 into payroll multiplication formulas shortchanges an employee by 12 minutes (0.2 hours) per shift.

How does the FLSA 7-minute rounding rule work? ▼

Under US Fair Labor Standards Act (FLSA 29 CFR § 785.48(b)), employers may round employee clock times to the nearest 15-minute increment using the 7-minute rule: minutes 1 through 7 round down to the previous quarter-hour, while minutes 8 through 14 round up to the next quarter-hour. The rounding must be neutral and average out fairly over time.

What is the difference between daily overtime and weekly overtime? ▼

Weekly overtime triggers when an employee exceeds 40 total regular hours in a single standard workweek (the federal FLSA standard). Daily overtime mandates overtime pay whenever an employee works more than 8 hours in a single workday, regardless of total weekly hours (required in jurisdictions like California, Alaska, and Nevada).

How do you calculate gross pay with overtime? ▼

Gross pay is calculated using the formula: Gross Pay = (Regular Hours * Base Hourly Rate) + (Overtime Hours * Base Hourly Rate * Overtime Multiplier). For standard time-and-a-half (1.5x) at a $25/hr wage with 5 overtime hours: (40 * $25) + (5 * $25 * 1.5) = $1,000 + $187.50 = $1,187.50.

How to Calculate IPv4 Subnets, Netmasks, and CIDR Blocks (Explained)

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

Free In-Browser Tool TOOLBOX UTILITY

IPv4 Subnet & CIDR Calculator

Interactive visual subnet calculator showing binary octets, IP ranges, bitmasks, and RFC 1918 classification.

Calculate Subnets with CIDR /24 →

What Is Subnetting & CIDR?

An IPv4 address is a 32-bit number typically written as four decimal octets separated by dots (e.g., 192.168.1.50).

Before Classless Inter-Domain Routing (CIDR) was standardized in RFC 4632, IPv4 addresses were split into rigid Class A, B, and C blocks, which caused immense IP waste. CIDR introduced variable-length subnet masking using slash notation (/N), where N (between 0 and 32) designates how many bits belong to the network prefix.

The Usable Host Calculation Formula

To calculate the number of assignable host addresses in any subnet:

$$\text{Host Bits } (H) = 32 - \text{CIDR Prefix}$$

$$\text{Total Addresses} = 2^H$$

$$\text{Usable Hosts} = 2^H - 2$$

Why Subtract 2?

Network Address (All host bits are 0): Identifies the subnet itself on routing tables.
Broadcast Address (All host bits are 1): Sends packets to all hosts on the subnet simultaneously.

CIDR Prefix Reference Table

CIDR Prefix	Subnet Mask	Total Addresses ($2^H$)	Usable Hosts ($2^H - 2$)	Typical Use Case
/30	`255.255.255.252`	4	2	Point-to-point router links
/29	`255.255.255.248`	8	6	Small cloud VPC subnets
/28	`255.255.255.240`	16	14	Small DMZ / firewall blocks
/26	`255.255.255.192`	64	62	Departmental LAN
/24	`255.255.255.0`	256	254	Standard home/office Wi-Fi
/23	`255.255.254.0`	512	510	Medium enterprise branch
/16	`255.255.0.0`	65,536	65,534	AWS / Azure Virtual Private Cloud
/8	`255.0.0.0`	16,777,216	16,777,214	Large ISP / National backbones

Binary Bitmasking: Finding Network and Broadcast IPs

Consider 10.0.15.35/20:

CIDR /20: 20 ones followed by 12 zeros.
Subnet Mask: 255.255.240.0.
Host Bits: $32 - 20 = 12 \implies 2^{12} = 4,096$ total IPs ($4,094$ usable hosts).
Network Address: Bitwise AND of 10.0.15.35 and 255.255.240.0 $\implies \mathbf{10.0.0.0}$.
Broadcast Address: Inverting the mask yields wildcard 0.0.15.255. Bitwise OR with Network IP $\implies \mathbf{10.0.15.255}$.
Usable Range: 10.0.0.1 to 10.0.15.254.

Eliminate manual subnet math errors with our .

Interactive Workbench LIVE

Calculate IPv4 Subnets, Netmasks, and CIDR Blocks (Explained)

Open Fullscreen ↗

Interactive visual subnet calculator showing binary octets, IP ranges, bitmasks, and RFC 1918 classification.

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 do you subtract 2 when calculating usable hosts in a subnet? ▼

Every standard IPv4 subnet reserves the very first address as the Network Identifier and the very last address as the Subnet Broadcast Address. These two addresses cannot be assigned to individual network interfaces or host machines.

What is CIDR slash notation (e.g., /24)? ▼

Classless Inter-Domain Routing (CIDR) slash notation indicates how many leading bits of the 32-bit IPv4 address belong to the network prefix. For example, /24 means the first 24 bits are 1s (255.255.255.0), leaving 8 bits (2^8 = 256 addresses) for hosts.

What are the standard RFC 1918 private IPv4 ranges? ▼

The three private IP ranges reserved for local networks are: 10.0.0.0/8 (10.0.0.0 – 10.255.255.255), 172.16.0.0/12 (172.16.0.0 – 172.31.255.255), and 192.168.0.0/16 (192.168.0.0 – 192.168.255.255).

How to Calculate Loan EMI: Mathematical Formula, Amortization, and Prepayment Strategies

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

Free In-Browser Tool TOOLBOX UTILITY

Loan EMI & Amortization Calculator

Interactive visual loan calculator with year-by-year amortization charts, interest breakdowns, and prepayment simulators.

Calculate Loan EMI & Amortization →

What Is an Equated Monthly Installment (EMI)?

An Equated Monthly Installment (EMI) is a fixed payment amount made by a borrower to a lender at a specified calendar date each month. Each EMI payment is split between two components:

Interest Component: The fee charged by the lender on the outstanding principal.
Principal Component: The portion of the payment that directly reduces the borrowed capital balance.

The Standard Reducing-Balance EMI Formula

The standard formula used across retail banks and financial institutions globally is:

$$\text{EMI} = \frac{P \cdot r \cdot (1 + r)^n}{(1 + r)^n - 1}$$

Where:

$P$ = Principal loan amount (e.g., $\$500,000$)
$r$ = Monthly interest rate $= \frac{\text{Annual Interest Rate}}{12 \times 100}$
$n$ = Total number of monthly installments (e.g., $20 \text{ years} \times 12 = 240 \text{ months}$)

Step-by-Step Calculation Example:

Consider a personal or home loan with:

Principal ($P$) = $\$100,000$
Annual Interest Rate = $12\%$
Monthly Rate ($r$) = $12 / (12 \times 100) = 0.01$
Tenure ($n$) = $5 \text{ years} \times 12 = 60 \text{ months}$

Calculate $(1 + r)^n = (1.01)^{60} \approx 1.8166967$
Calculate Numerator: $100,000 \times 0.01 \times 1.8166967 \approx 1,816.70$
Calculate Denominator: $1.8166967 - 1 = 0.8166967$
Divide: $\text{EMI} = 1,816.70 / 0.8166967 \approx \mathbf{\$2,224.44\text{ per month}}$

Understanding the Amortization Curve

A major surprise for first-time borrowers is reviewing their amortization schedule. In the first 30% of your loan tenure, up to 70% of each EMI payment covers interest!

graph LR Year1[Year 1-5: High Outstanding Principal] --> HighInterest[70% of EMI is Interest] HighInterest --> SlowPrincipal[Only 30% reduces Principal] SlowPrincipal --> MidLoan[Mid-Loan Crossover Point] MidLoan --> LowInterest[30% Interest / 70% Principal] LowInterest --> FinalYears[Final Years: Rapid Debt Clearance]

Amortization Breakdown Table ($100k Loan at 12% over 5 Years):

Period	Beginning Balance	EMI Payment	Interest Paid	Principal Paid	Ending Balance
Month 1	$100,000.00	$2,224.44	$1,000.00	$1,224.44	$98,775.56
Month 12	$85,420.10	$2,224.44	$854.20	$1,370.24	$84,049.86
Month 36	$51,620.30	$2,224.44	$516.20	$1,708.24	$49,912.06
Month 60	$2,202.42	$2,224.44	$22.02	$2,202.42	$0.00

Prepayment Strategies: How to Save Thousands in Interest

Because interest compounds against remaining principal, every extra dollar paid directly toward principal in the early years yields exponential interest savings:

The 13th EMI Strategy: Paying just one additional EMI payment every calendar year directly toward principal can reduce a 20-year mortgage by 3 to 4 years.
Annual Step-Up: Increasing your monthly payment by 5% each year as your income grows can cut your loan tenure by nearly half.

Model your exact loan numbers and compare prepayment scenarios with our .

Interactive Workbench LIVE

Calculate Loan EMI: Mathematical Formula, Amortization, and Prepayment Strategies

Open Fullscreen ↗

Calculate monthly installments, view interactive interest vs principal amortization charts, and simulate prepayment savings.

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

What is the mathematical formula used to calculate loan EMI? ▼

The reducing balance formula is: EMI = [P x r x (1 + r)^n] / [(1 + r)^n - 1], where P is Principal loan amount, r is monthly interest rate (annual rate divided by 12 and 100), and n is the total number of monthly installments.

Why does the majority of early EMI payments go toward interest rather than principal? ▼

In reducing balance loans, interest is computed each month against the remaining outstanding principal. Because the principal balance is highest during the initial years, the monthly interest charge is also at its peak. As you pay down principal, the interest share declines and principal repayment accelerates.

How much can you save by paying one additional EMI every year? ▼

On a typical 20-year home loan at 8.5% interest, making just one extra EMI payment each year directly toward principal can reduce your overall loan tenure by approximately 3 to 4 years and save substantial cumulative interest.

How to Calculate Time Differences Across Global Time Zones (Accurately)

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

Free In-Browser Tool TOOLBOX UTILITY

World Time Zone Converter

Drag-and-drop global timeline slider with automatic DST calculation and multi-city meeting planner.

Convert Time Zones Now →

The Hidden Complexity of Time Zone Calculations

Coordinating meetings and data synchronization across distributed teams appears simple on paper, but time calculations are famously error-prone.

A common pitfall is assuming that the time difference between two cities is constant year-round. In reality, because governments shift Daylight Saving Time on different weekends—or have repealed DST altogether—the time difference between London (Europe/London) and New York (America/New_York) fluctuates between 4 hours and 5 hours twice every year!

Why You Must Rely on the IANA Time Zone Database

Never calculate time zones using three-letter abbreviations like EST, PST, or CST. These strings suffer from three fatal flaws:

Severe Naming Collisions: BST represents British Summer Time (UTC+1), Bangladesh Standard Time (UTC+6), and Bougainville Standard Time (UTC+11).
Ignorance of DST: EST strictly means Eastern Standard Time (UTC-5). In summer, New York observes EDT (UTC-4). Specifying EST in summer produces a 1-hour error.
Political Changes: Countries periodically change offsets or abandon DST.

The IANA Time Zone Database (also known as the Olson or tz database) uses geographical identifiers in the format Area/Location:

America/New_York
Europe/London
Asia/Kolkata
Asia/Tokyo

Modern browser JavaScript natively supports the IANA database via Intl.DateTimeFormat:

const nyTime = new Intl.DateTimeFormat('en-US', {
 timeZone: 'America/New_York',
 timeStyle: 'medium',
 dateStyle: 'short'
}).format(new Date());

The Time Difference Formula

To calculate the time difference between City A (Source) and City B (Target):

$$\Delta T = \text{UTC Offset}_B - \text{UTC Offset}_A$$

Example: London to Tokyo

London in Winter (Europe/London): $\text{UTC}+0$
Tokyo (Asia/Tokyo): $\text{UTC}+9$
$\Delta T = (+9) - (0) = +9\text{ hours}$ (Tokyo is 9 hours ahead of London).

Example: San Francisco to New York

San Francisco in Summer (America/Los_Angeles): $\text{UTC}-7$
New York in Summer (America/New_York): $\text{UTC}-4$
$\Delta T = (-4) - (-7) = +3\text{ hours}$ (New York is 3 hours ahead of San Francisco).

Handling the International Date Line

When the difference calculation crosses midnight:

If Target Time $\ge 24:00$: Add 1 calendar day and subtract 24 hours.
If Target Time $< 00:00$: Subtract 1 calendar day and add 24 hours.

Avoid mental arithmetic errors by using our , which provides a visual multi-city timeline slider with instant date boundary markers.

Interactive Workbench LIVE

Calculate Time Differences Across Global Time Zones (Accurately)

Open Fullscreen ↗

Compare global timelines, calculate UTC offsets with automatic Daylight Saving Time adjustment, and plan meetings across timezones.

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 it risky to use three-letter abbreviations like EST or CST for conversions? ▼

Three-letter abbreviations are ambiguous and often do not account for Daylight Saving Time. For example, CST can represent Central Standard Time (UTC-6) in the US, China Standard Time (UTC+8), or Cuba Standard Time (UTC-5). Always use canonical IANA city identifiers like America/Chicago or Asia/Shanghai.

How does Daylight Saving Time (DST) affect time zone calculations? ▼

DST shifts local clocks forward by 1 hour in spring and backward by 1 hour in autumn. Because different countries switch to DST on different calendar dates (or do not observe it at all), the time difference between two cities can fluctuate by 1 to 2 hours depending on the month.

What is UTC and why is it the universal baseline for time calculations? ▼

Coordinated Universal Time (UTC) is the primary time standard by which the world regulates clocks and time. UTC does not observe Daylight Saving Time, providing a constant reference point for calculating positive (+) and negative (-) offsets worldwide.

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.

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.

How to Generate SHA-256 and MD5 Hashes Online (Securely in Browser)

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

Free In-Browser Tool TOOLBOX UTILITY

Cryptographic Hash Generator

Generate instant SHA-256, MD5, and SHA-512 hashes with uppercase/lowercase toggles and binary file checksum support.

Generate SHA-256 Hash Now →

What Is a Cryptographic Hash Function?

A cryptographic hash function is a mathematical algorithm that transforms an arbitrary block of input data into a fixed-size bit string (a digest or checksum).

Every secure cryptographic hash possesses four essential properties:

Deterministic: The same input always produces the exact same hash.
Quick Computation: The digest can be computed rapidly for any data stream.
Pre-Image Resistance (One-Way): Given a hash $H$, it is computationally infeasible to find the original message $M$ such that $\text{hash}(M) = H$.
The Avalanche Effect: Modifying a single character or bit in the input radically alters the resulting digest.

Algorithm Comparison: MD5 vs SHA-1 vs SHA-256 vs SHA-512

Algorithm	Digest Size	Collision Resistance	Status	Primary Modern Use Case
MD5 (RFC 1321)	128 bits (32 hex)	❌ Broken ($2^{16}$ operations)	Insecure for Crypto	Legacy file integrity checksums
SHA-1 (FIPS 180-1)	160 bits (40 hex)	❌ Broken (SHAttered in 2017)	Deprecated	Git commit object identification
SHA-256 (FIPS 180-4)	256 bits (64 hex)	✅ Unbroken ($2^{128}$ complexity)	Gold Standard	TLS certificates, Bitcoin, file verification
SHA-512 (FIPS 180-4)	512 bits (128 hex)	✅ Unbroken ($2^{256}$ complexity)	Maximum Security	High-security government & banking applications

Why You Should Never Hash Passwords with Plain SHA-256

While SHA-256 is ideal for verifying file integrity and code signatures, it is dangerous to hash passwords directly with plain SHA-256 or MD5.

Modern GPUs can compute over 10 billion SHA-256 hashes per second. Attackers with precomputed rainbow tables can crack unsalted SHA-256 passwords in seconds. For password storage, always use slow, memory-hard key derivation functions like Argon2id, bcrypt, or PBKDF2.

Client-Side Hashing with the Web Crypto API

Modern web browsers support hardware-accelerated cryptographic operations natively via window.crypto.subtle:

async function calculateSHA256(message) {
 const encoder = new TextEncoder();
 const data = encoder.encode(message);
 const hashBuffer = await crypto.subtle.digest('SHA-256', data);
 const hashArray = Array.from(new Uint8Array(hashBuffer));
 return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

Because execution happens within your device’s browser sandbox, your sensitive data is completely protected from interception. Test it right now with our .

Interactive Workbench LIVE

Generate SHA-256 and MD5 Hashes Online (Securely in Browser)

Open Fullscreen ↗

Generate instant SHA-256, MD5, and SHA-512 hashes with uppercase/lowercase toggles and binary file checksum support.

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 MD5 no longer considered cryptographically secure? ▼

MD5 is vulnerable to collision attacks, where two distinct input strings produce the exact same 128-bit hash digest. In 2008, security researchers demonstrated forging rogue SSL certificates using MD5 collisions. However, MD5 is still widely used as a fast, non-cryptographic checksum for file transfer verification.

Can a SHA-256 hash be decrypted back to its original input? ▼

No. Cryptographic hash functions are strictly one-way mathematical algorithms, not encryption. You cannot reverse or decrypt a hash digest. The only way to find the original input is via brute-force dictionary attacks (rainbow tables).

Does hashing files in Toolbox upload my data to a server? ▼

No. The hashing engine uses the browser's native Web Cryptography API (crypto.subtle.digest) to compute digests locally on your CPU/GPU. Zero bytes of your file or text are transmitted over the internet.

JWT Security 101: How to Decode, Inspect, and Verify Claims Client-Side

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

Free In-Browser Tool TOOLBOX UTILITY

JWT Token Inspector & Decoder

Analyze JWT expiration, token issuance, audience, and signature algorithms locally with real-time expiration count-downs.

Inspect JWT Token Safely →

What Is a JSON Web Token (JWT)?

Defined by RFC 7519, a JSON Web Token is an open, compact, URL-safe container for transferring claims between two parties. JWTs are the dominant authentication mechanism in modern single-page applications (SPAs), microservice architectures, and OAuth 2.0 / OpenID Connect (OIDC) workflows.

A JWT consists of three distinct parts separated by dots (.):

Header.Payload.Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3MDAwMDAwMDB9.4pz-KE...

The Three Components of a JWT

1. The Header

The header describes the cryptographic metadata and token type:

{
 "alg": "HS256",
 "typ": "JWT"
}

alg: The cryptographic signing algorithm (e.g., HS256, RS256, ES256).
typ: Token type, typically "JWT".

2. The Payload (Claims)

The payload contains statements about an entity (usually the authenticated user) and additional session metadata.

Standard Registered Claims:

iss (Issuer): Identifies the authority that issued the JWT.
sub (Subject): Identifies the principal subject of the token (e.g., user ID).
aud (Audience): Identifies the intended recipients or resource servers.
exp (Expiration Time): Unix epoch timestamp after which the token must not be accepted.
nbf (Not Before): Identifies the timestamp before which the token is invalid.
iat (Issued At): Timestamp recording when the token was generated.

3. The Signature

The signature validates that the token was neither tampered with nor forged in transit. For HMAC-SHA256:

HMACSHA256(
 base64UrlEncode(header) + "." + base64UrlEncode(payload),
 secret
)

Critical JWT Security Pitfalls

1. The “None” Algorithm Attack

In early implementations of RFC 7519, servers supported unsigned tokens where "alg": "none". Attackers bypassed authentication by altering the payload to grant admin privileges and setting "alg": "none" with an empty signature. Modern verification libraries strictly whitelist approved algorithms (algorithms: ['RS256']).

2. Key Confusion (Asymmetric to Symmetric)

When an API verifies tokens using an asymmetric algorithm (like RS256), the server uses a public key to verify and a private key to sign. In key confusion attacks, an adversary changes the header to "alg": "HS256" and signs the token using the server’s publicly accessible public key as the HMAC secret! Vulnerable servers verifying with jwt.verify(token, key) mistakenly treat the public key string as a shared symmetric secret.

3. Leaking Production Secrets to Web Tools

Never paste live customer session tokens or sensitive API tokens into third-party servers. Using our ensures parsing executes purely in local browser memory.

Interactive Workbench LIVE

JWT Security 101: How to Decode, Inspect, and Verify Claims Client-Side

Open Fullscreen ↗

Decode and inspect JWT headers, standard claims, and expiration timestamps securely in your browser.

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 a JWT token encrypted? ▼

No. Standard JWTs (RFC 7519) are signed, not encrypted. The header and payload are simply Base64Url-encoded JSON strings. Anyone with access to the token string can decode and read the underlying claims in plaintext.

Why is it dangerous to paste production JWTs into random online debuggers? ▼

Many online token inspectors transmit tokens over HTTP to their backend servers for logging or telemetry. If your token contains confidential user IDs, role permissions, or OAuth access scopes, server-side log ingestion creates severe security liabilities. Always use client-side tools.

What is the 'algorithm none' vulnerability in JWT verification? ▼

The 'none' algorithm is an optional spec in RFC 7519 for unsigned tokens. If an insecure server verification library accepts alg: 'none', an attacker can strip the signature, modify the payload (e.g. set 'admin': true), and forge unauthorized authentication.

Understanding UUID v4 vs v7: Generation, Differences, and Database Indexing

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

Free In-Browser Tool TOOLBOX UTILITY

UUID & GUID Generator

Generate cryptographically random UUID v4 or time-ordered UUID v7 with custom casing, batch generation, and zero server logging.

Generate UUID v7 Instantly →

What Is a UUID?

A Universally Unique Identifier (UUID), standardized by RFC 4122 and recently modernized by RFC 9562, is a 128-bit value formatted as 32 hexadecimal digits separated by hyphens in an 8-4-4-4-12 pattern:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

M represents the UUID version (e.g., 4 for random, 7 for Unix epoch time-sorted).
N represents the variant (typically 8, 9, a, or b, encoding the 10xx binary variant).

The Hidden Penalty of UUID v4 in Databases

For over two decades, UUID v4 has been the default choice for distributed systems because it requires no central coordination:

f47ac10b-58cc-4372-a567-0e02b2c3d479 (v4: 122 random bits)

However, when used as a primary key in relational databases (such as PostgreSQL, MySQL InnoDB, or SQL Server), UUID v4 causes severe performance degradation as tables scale beyond millions of rows:

B-Tree Index Fragmentation: B-Tree indexes require sorted keys. Because UUID v4 values are completely random, new inserts land in arbitrary locations throughout the index tree.
Page Splits & Write Amplification: When an index page fills up, the database engine is forced to split the page into two, rewriting existing data to disk.
Buffer Pool Cache Eviction: Because incoming writes touch random pages across the entire index, the database cannot keep the “hot” working set in memory, leading to heavy random SSD I/O.

Enter UUID v7: Time-Sorted Distributed Identifiers

Published in RFC 9562, UUID v7 directly eliminates index fragmentation while preserving decentralized generation:

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | ver | rand_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UUID v7 Bit Anatomy:

Bits 0–47 (48 bits): Big-endian unsigned 48-bit integer recording the Unix timestamp in milliseconds.
Bits 48–51 (4 bits): Version nibble set to 0111 (0x7).
Bits 52–63 (12 bits): Sub-millisecond sequence or pseudo-random bits (rand_a).
Bits 64–65 (2 bits): RFC variant bits set to 10.
Bits 66–127 (62 bits): Cryptographically secure random entropy (rand_b).

Because the leading 48 bits track real-world time, UUID v7 values sort sequentially by creation time. In B-Tree indexes, new inserts append directly to the rightmost leaf page, reducing page splits to nearly zero.

Feature & Performance Comparison

Attribute	Auto-Increment `BIGINT`	UUID v4 (Random)	UUID v7 (Time-Ordered)
Standard Spec	Database Engine Native	RFC 4122	RFC 9562
Bit Length	64 bits	128 bits	128 bits
Decentralized Generation	❌ (Requires centralized DB lock)	✅ (Fully decentralized)	✅ (Fully decentralized)
B-Tree Index Locality	✅ Optimal sequential appends	❌ Severe random page splits	✅ Optimal sequential appends
Information Leakage	⚠️ High (Reveals order/volume)	✅ Zero	⚠️ Leaks millisecond timestamp
Distributed Collisions	Single point of failure	$1 \text{ in } 2^{122}$	$1 \text{ in } 2^{74} \text{ per millisecond}$

How to Generate UUIDs Client-Side in Your Browser

In modern browsers, generating cryptographically secure identifiers relies on the Web Cryptography API (crypto.getRandomValues):

// Native Web Crypto UUID v4
const uuidV4 = crypto.randomUUID();
console.log(uuidV4); // e.g. 3b241101-e2bb-4255-8caf-4136c566a962

For UUID v7, client-side tools pack the current Date.now() timestamp into the top 48 bits, set the 0x7 version bits, and populate the remaining 74 bits with cryptographically secure random bytes from crypto.getRandomValues(new Uint8Array(10)).

Try generating batch UUIDs with our .

Interactive Workbench LIVE

UUID v4 vs v7: Generation, Differences, and Database Indexing

Open Fullscreen ↗

Generate cryptographically secure, time-sortable UUID v7 and random UUID v4 identifiers directly in your browser.

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 UUID v7 better than UUID v4 for database primary keys? ▼

UUID v7 starts with a 48-bit Unix millisecond timestamp, making newly generated IDs monotonically increasing. When inserted into B-Tree database indexes (PostgreSQL, MySQL), new records append sequentially to the leaf nodes rather than causing random page splits and disk cache churn.

Are UUID v7 identifiers cryptographically secure? ▼

Yes. UUID v7 combines a 48-bit timestamp with 74 bits of cryptographically secure random entropy. With 74 bits of entropy per millisecond, the probability of a collision in distributed environments is negligible.

Is UUID v7 backwards-compatible with standard 36-character UUID parsers? ▼

Yes. UUID v7 adheres strictly to the canonical 8-4-4-4-12 string layout specified in RFC 9562, featuring the standard version nibble (7) and variant bits (10xx). Any standard UUID parser can read, validate, and store it.

Toolbox Guides & Technical Articles | 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

GST Calculation in India After GST 2.0: Slabs, Reverse GST, and CGST/SGST Splits

GST Tax Calculator

What Changed with GST 2.0

Forward GST: Adding Tax to a Base Price

Reverse GST: Extracting Tax from an Inclusive Total

Handy inclusive divisors

CGST, SGST, UTGST, and IGST

Rounding, Precision, and Reconciliation

Invoice fields the arithmetic must support

Worked Example: A Mixed-Rate Invoice

Step-by-Step: Using the Toolbox GST Calculator

GST Calculation in India After GST 2.0: Slabs, Reverse GST, and CGST/SGST Splits

Frequently Asked Questions

HMAC-SHA256 Webhook Signature Verification: RFC 2104 Internals and Provider Formats

HMAC-SHA256 Webhook Signature Verification: RFC 2104 Internals and Provider Formats

HMAC Signature Generator & Verifier

The Problem HMAC Solves

The RFC 2104 Construction

Why not H(secret || message)?

Block sizes and digest lengths

Provider Formats Compared

Stripe

GitHub

Shopify

The Four Failure Modes

1. The body was parsed before you hashed it

2. Non-constant-time comparison

3. No replay protection

4. Signature comparison as the only gate

Hex, Base64, or Base64url — Match the Provider Exactly

Computing HMAC in the Browser

Operational Checklist

Choosing the Hash

Step-by-Step: Debugging a Failing Signature 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

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

HTTP Header Security Auditor

Headers Are the Cheapest Security You Will Ever Deploy

Content-Security-Policy: The One That Does the Work

The Modern Strict Policy

Roll It Out in Report-Only Mode First

Directives That Do Not Behave as Expected

Strict-Transport-Security

Clickjacking, Sniffing, and Referrer Leakage

X-Content-Type-Options: nosniff

X-Frame-Options

Referrer-Policy

Permissions-Policy

Cross-Origin Isolation: COOP, COEP, CORP

Why not `H(secret || message)`?

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

`X-Content-Type-Options: nosniff`

`X-Frame-Options`

`Referrer-Policy`

`Permissions-Policy`

The `lastIndex` Trap