The answer is usually uncomfortable. I'll show the code first, then the numbers.

The model

Card issuers differ in the details, but a typical minimum payment is:

1% of the balance + that month's interest, with a floor of about $25 (or the whole balance if that's smaller).

Interest is the APR ÷ 12, applied to the balance. Strictly speaking, most cards use an average daily balance, but monthly compounding gets within a few dollars.

function simulate(balance, apr, paymentFn, maxMonths = 1200) {
  const r = apr / 12;
  let months = 0, interestPaid = 0;
  while (balance > 0.005) {
    if (months >= maxMonths) return null;        // never pays off
    const interest = balance * r;
    const pay = Math.min(paymentFn(balance, interest), balance + interest);
    if (pay <= interest) return null;             // negative amortization
    interestPaid += interest;
    balance = balance + interest - pay;
    months++;
  }
  return { months, interestPaid };
}

const minimum = (b, i) => Math.max(25, b * 0.01 + i);
const fixed = amount => () => amount;

Passing the payment rule in as a function keeps the same loop working for "pay the minimum", "pay $250 a month" and "pay 3% of the balance".

The numbers for a $5,000 balance at 24% APR

simulate(5000, 0.24, minimum);      // { months: 234, interestPaid: ≈ 8887 }
simulate(5000, 0.24, fixed(150));   // { months: 56,  interestPaid: ≈ 3322 }
simulate(5000, 0.24, fixed(250));   // { months: 26,  interestPaid: ≈ 1449 }
simulate(5000, 0.24, fixed(100));   // null: $100 never covers the $100 of interest

Paying only the minimum takes 234 months, or nearly 19.5 years, and costs about $8,900 in interest. That's more than the original balance. If you lock in a fixed $250 a month, which is the first month's minimum, you're done in just over two years.

That gap comes from how the minimum shrinks as the balance shrinks. Each month you pay a little less, so the principal goes down more and more slowly. If you keep paying a fixed amount instead, the share that goes to principal grows every month.

Edge case 1: payments that never win

fixed(100) returns null because 24% / 12 = 2% a month, and 2% of $5,000 is exactly $100. The balance never moves. Any payment at or below the monthly interest gives you negative amortization: the balance stays put or grows. A calculator should say so plainly rather than loop forever. That's why there's both a pay <= interest check and a maxMonths guard.

Edge case 2: the last payment

Without Math.min(..., balance + interest), the final month overpays and you get a negative balance and inflated interest totals. Real statements simply bill whatever is left.

Edge case 3: cents

Issuers round interest to the cent each cycle. If you want to match a statement exactly, keep the balance in integer cents:

const interest = Math.round(balanceCents * r); // integer cents

Over 234 months, float drift adds up to a few cents. That's harmless for planning, but people do notice when it doesn't match.

Is there a formula at all?

For a fixed payment there is. Solving the annuity equation for n gives:

const monthsToPayoff = (B, apr, M) => {
  const r = apr / 12;
  return -Math.log(1 - (B * r) / M) / Math.log(1 + r);
};
monthsToPayoff(5000, 0.24, 250); // ≈ 25.6 → 26 payments

It returns NaN when M <= B·r, which is the same negative-amortization case. For percentage-based minimums with a floor, the simulation is simpler and easier to trust.

Avalanche vs snowball in five more lines

Once you have simulate, comparing payoff strategies across several cards is a loop. Each month, pay the minimum on every card. Then put the extra money on the card with the highest APR (avalanche) or the smallest balance (snowball). Avalanche always pays the least interest. Snowball gives you quick wins, and for many people that's what keeps them going. The simulation can tell you exactly how many dollars that motivation costs.

Try it with your own numbers

I built a small, free credit card payoff calculator on this same loop. It runs entirely in the browser, with no sign-up and nothing sent anywhere. Enter a balance, APR and payment, and it shows the months and total interest.

The main takeaway doesn't need a calculator, though. Pick a fixed payment and keep paying it, even as the required minimum falls. That one habit is the difference between 2 years and 19.

The formula

For a loan of principal P, a monthly rate r (annual rate ÷ 12) and n monthly payments:

M = P · r / (1 − (1 + r)^−n)

function monthlyPayment(principal, annualRate, months) {
  const r = annualRate / 12;
  if (r === 0) return principal / months;   // 0% promo loans: avoid divide-by-zero
  return principal * r / (1 - Math.pow(1 + r, -months));
}

monthlyPayment(25000, 0.07, 60); // ≈ 495.03

Where it comes from (the short version)

A loan is "fair" when the present value of all your payments equals the amount borrowed. A payment made k months from now is worth M / (1 + r)^k today, so:

P = M/(1+r) + M/(1+r)^2 + … + M/(1+r)^n

That's a geometric series. Summing it gives P = M · (1 − (1+r)^−n) / r, and solving for M gives the formula above. That's the whole derivation.

The amortization schedule

Each month, interest is charged on the remaining balance, and whatever is left of the payment reduces the principal:

function schedule(principal, annualRate, months, extra = 0) {
  const r = annualRate / 12, pay = monthlyPayment(principal, annualRate, months);
  let balance = principal, rows = [];
  while (balance > 0.005 && rows.length < 1000) {
    const interest = balance * r;
    const toPrincipal = Math.min(pay + extra - interest, balance);
    balance -= toPrincipal;
    rows.push({ month: rows.length + 1, interest, toPrincipal, balance });
  }
  return rows;
}

For $25,000 at 7% over 5 years, the first payment of $495.03 is $145.83 interest and only $349.20 principal. By the final year, almost all of each payment goes to principal. That's why loans feel like they barely move at first.

Total interest over the full term is about $4,702.

Why extra payments are so effective

Every extra dollar goes straight to principal, and principal is what interest is charged on. So it saves interest for every remaining month.

const base = schedule(25000, 0.07, 60);
const plus = schedule(25000, 0.07, 60, 100);
const sum = rows => rows.reduce((s, x) => s + x.interest, 0);
console.log(base.length, sum(base).toFixed(0));  // 60 months, ~4702
console.log(plus.length, sum(plus).toFixed(0));  // 49 months, ~3763

Adding $100 a month finishes 11 months sooner and saves roughly $940 in interest. Before you do this, check that your lender applies extra payments to principal and doesn't charge prepayment penalties.

Why two calculators disagree by a cent

If you compare your result with a bank statement, you'll sometimes be off by a few cents. Common reasons:

1. Rounding each month. Banks round interest and payments to the cent every period. A pure floating-point schedule doesn't. To match a statement, round each row: Math.round(x * 100) / 100, or work in integer cents.
2. The last payment. Rounding errors accumulate, so lenders usually adjust the final payment. The Math.min(..., balance) above handles that.
3. Day-count conventions. Some loans accrue interest daily (actual/365) rather than as a clean 1/12 of the annual rate, so months with 31 days cost a bit more.
4. APR vs interest rate. APR includes fees. The payment formula uses the note rate, not the APR.
5. Floating point. 0.1 + 0.2 !== 0.3 in JavaScript. It rarely matters for display, but for money logic you persist, prefer integer cents or a decimal library.

Edge cases to handle

• annualRate === 0 → straight division (handled above).
• Very long terms with tiny rates → Math.pow is fine; avoid looping to compound.
• Validate inputs: negative months or a rate entered as 7 instead of 0.07 is the classic bug. Decide whether your UI takes percentages and convert once.

Try it

If you'd rather not run this in a console, LoanMath is a free calculator I built on exactly this math, with an amortization schedule (there's a separate extra-payment calculator for the comparison above).

This post explains the math and isn't financial advice. Your loan agreement's terms always win.

Here's a minimal but real implementation.

Setup

<input type="file" id="files" accept="application/pdf" multiple>
<button id="merge">Merge</button>
<script src="https://unpkg.com/pdf-lib@1.17.1/dist/pdf-lib.min.js"></script>

(Or npm i pdf-lib and import { PDFDocument, degrees } from 'pdf-lib'. In production, self-host the file or pin it with Subresource Integrity rather than loading a CDN script unpinned.)

Merging

The core idea: create an empty document, then copy pages from each source into it.

const { PDFDocument } = PDFLib;

async function mergePdfs(files) {
  const out = await PDFDocument.create();
  for (const file of files) {
    const src = await PDFDocument.load(await file.arrayBuffer());
    const pages = await out.copyPages(src, src.getPageIndices());
    pages.forEach(p => out.addPage(p));
  }
  return out.save(); // Uint8Array
}

document.getElementById('merge').onclick = async () => {
  const files = [...document.getElementById('files').files];
  const bytes = await mergePdfs(files);
  download(bytes, 'merged.pdf');
};

function download(bytes, name) {
  const url = URL.createObjectURL(new Blob([bytes], { type: 'application/pdf' }));
  const a = Object.assign(document.createElement('a'), { href: url, download: name });
  a.click();
  setTimeout(() => URL.revokeObjectURL(url), 1000);
}

Why copyPages and not just addPage(src.getPage(0))? Each page refers to objects that belong to its own document: fonts, images, content streams. copyPages deep-copies those references into the target document. Adding a page that belongs to another document doesn't work.

Order matters. input.files comes back in whatever order the OS file picker returns, which isn't always the order the user means. A real UI should show the list and let users reorder it before merging.

Extracting a page range

The same pattern with a subset of indices:

async function extract(file, from, to) {           // 1-based, inclusive
  const src = await PDFDocument.load(await file.arrayBuffer());
  const out = await PDFDocument.create();
  const idx = Array.from({ length: to - from + 1 }, (_, i) => from - 1 + i);
  (await out.copyPages(src, idx)).forEach(p => out.addPage(p));
  return out.save();
}

"Split every page into its own file" is just this in a loop. Zip the results with something like JSZip if there are many.

Rotating pages

const { degrees } = PDFLib;

async function rotateAll(file, by = 90) {
  const doc = await PDFDocument.load(await file.arrayBuffer());
  for (const page of doc.getPages()) {
    const current = page.getRotation().angle;
    page.setRotation(degrees((current + by) % 360));
  }
  return doc.save();
}

Rotation is stored as a page attribute, so this is lossless and instant. No re-rendering happens.

Things that will bite you

• Encrypted PDFs. pdf-lib can't decrypt password-protected files, and load() throws on them by default. Catch the error and tell the user to remove the password first. { ignoreEncryption: true } exists, but it doesn't actually decrypt anything, so the output is often broken.
• Memory. Everything sits in RAM. A few hundred MB of scans can crash a mobile tab, so process files one at a time and warn above a size threshold.
• Form fields. Copying pages from several documents with AcroForm fields can produce duplicate field names. If forms matter, flatten them first (doc.getForm().flatten()).
• File size. Merged output is roughly the sum of the inputs. pdf-lib doesn't recompress images. If you need smaller files, that's a separate step.

Proving it stays local

Users have no reason to take "we don't upload your files" on faith. Make it checkable: serve the page as static files, avoid sending file data to analytics, and invite people to watch the Network tab. With the code above, the only request should be the initial script load.

I used exactly this approach for PDFPocket's merge tool, a free set of browser-only PDF utilities (merge, split, rotate, JPG to PDF). Feel free to use it as a reference, or take the snippets above and build your own in an afternoon.

The pipeline

File  →  decode (ImageBitmap)  →  draw on canvas at target size  →  encode (toBlob)  →  Blob / download

Each step has one browser API and at least one gotcha.

1. Decode the file

const input = document.querySelector('input[type=file]');
input.addEventListener('change', async () => {
  const file = input.files[0];
  const bitmap = await createImageBitmap(file, { imageOrientation: 'from-image' });
  // bitmap.width / bitmap.height are the real pixel dimensions
});

createImageBitmap decodes off the main thread in most browsers and accepts a File directly. The imageOrientation: 'from-image' option tells it to respect the EXIF orientation tag. Phone photos are often stored sideways with a "rotate 90°" flag. Current browsers apply that flag by default, but setting it explicitly documents the intent.

2. Resize: this is where most of the savings come from

People reach for the quality slider first, but dimensions matter more. A 4032×3024 phone photo shown in an 800 px column is carrying about 19× more pixels than it needs.

function fit(w, h, maxW, maxH) {
  const scale = Math.min(1, maxW / w, maxH / h); // never upscale
  return [Math.round(w * scale), Math.round(h * scale)];
}

const [w, h] = fit(bitmap.width, bitmap.height, 1600, 1600);
const canvas = new OffscreenCanvas(w, h);           // or document.createElement('canvas')
const ctx = canvas.getContext('2d');
ctx.imageSmoothingQuality = 'high';
ctx.drawImage(bitmap, 0, 0, w, h);
bitmap.close(); // free memory early, big photos are tens of MB decoded

For very large downscales (say 8×), a single drawImage can look a bit soft or aliased. Halving the size in a few steps gives cleaner results.

3. Encode with a quality setting

const blob = await canvas.convertToBlob({ type: 'image/webp', quality: 0.8 });
// with a regular <canvas>: canvas.toBlob(cb, 'image/webp', 0.8)

• quality (0–1) applies to lossy formats (image/jpeg, image/webp) and is ignored for PNG.
• For photos, 0.75–0.85 is usually the sweet spot. Below about 0.6, artifacts show up around edges and in skies.
• Feature-detect WebP encoding. If a browser can't encode the type you ask for, it quietly falls back to PNG. Check blob.type afterwards:

if (blob.type !== 'image/webp') {
  // fall back to JPEG
}

4. Don't make it bigger

Re-encoding an already well-compressed JPEG can produce a larger file. Always compare sizes and keep the original if you didn't win:

const result = blob.size < file.size ? blob : file;

Gotchas worth knowing

Transparency. JPEG has no alpha channel, so transparent PNG pixels turn black. Fill the canvas with white first (ctx.fillStyle = '#fff'; ctx.fillRect(0, 0, w, h)) or keep WebP/PNG for images with transparency.

Metadata is dropped. Canvas re-encoding strips EXIF, including GPS location. That's usually a privacy feature for images you publish, but tell your users, because photographers sometimes want their copyright metadata kept.

Memory. A decoded 24-megapixel image is about 96 MB of RGBA. On phones, process files one at a time, call bitmap.close(), and consider a Web Worker with OffscreenCanvas so the UI stays responsive.

Color profiles. Wide-gamut (Display P3) photos can shift slightly when drawn to a default sRGB canvas. For web publishing this is normally fine, but it's worth knowing if a user reports "my colors changed".

Putting it together

async function compress(file, { max = 1600, type = 'image/webp', quality = 0.8 } = {}) {
  const bmp = await createImageBitmap(file, { imageOrientation: 'from-image' });
  const [w, h] = fit(bmp.width, bmp.height, max, max);
  const c = new OffscreenCanvas(w, h);
  const ctx = c.getContext('2d');
  if (type === 'image/jpeg') { ctx.fillStyle = '#fff'; ctx.fillRect(0, 0, w, h); }
  ctx.imageSmoothingQuality = 'high';
  ctx.drawImage(bmp, 0, 0, w, h);
  bmp.close();
  let out = await c.convertToBlob({ type, quality });
  if (out.type !== type) out = await c.convertToBlob({ type: 'image/jpeg', quality });
  return out.size < file.size ? out : file;
}

About 20 lines and no dependencies. It handles most "make this photo small enough to upload" cases.

When to use a real encoder instead

Canvas encoders are tuned for speed, not maximum compression. If you need the smallest possible files, such as for a build pipeline or a CDN, tools like sharp/libvips, MozJPEG or libavif (also available as WebAssembly) will beat toBlob at the same visual quality.

If you just want to try the browser approach on your own photos without writing code, PixSquish is a small free tool I made that runs this kind of pipeline entirely client-side. Open DevTools → Network while you use it and you'll see the image never leaves the page.

That ease is also the point of this post. The thing that's easy for you to read is just as easy for anyone else to read.

The shape of a JWT

A JWT (RFC 7519) in its common signed form (JWS) has three parts separated by dots:

xxxxx.yyyyy.zzzzz
header.payload.signature

• Header: JSON that describes the token, usually {"alg":"HS256","typ":"JWT"}.
• Payload: JSON "claims" such as sub (subject / user id), exp (expiry), iat (issued at), plus anything custom.
• Signature: a MAC or digital signature over header.payload, made with a secret or private key.

The header and payload are Base64URL-encoded, not encrypted. Base64URL is Base64 with - instead of +, _ instead of /, and the trailing = padding removed.

Decoding it yourself

function base64UrlDecode(str) {
  // Base64URL -> Base64
  let b64 = str.replace(/-/g, '+').replace(/_/g, '/');
  // restore padding
  while (b64.length % 4) b64 += '=';
  // atob gives a "binary string"; decode as UTF-8 so non-ASCII claims survive
  const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));
  return new TextDecoder().decode(bytes);
}

function decodeJwt(token) {
  const [h, p, s] = token.split('.');
  if (!h || !p) throw new Error('Not a JWT');
  return {
    header: JSON.parse(base64UrlDecode(h)),
    payload: JSON.parse(base64UrlDecode(p)),
    signature: s, // raw bytes, Base64URL; not human-readable
  };
}

Try it with the classic example token from the spec ecosystem:

const t = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.' +
  'eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.' +
  'SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

console.log(decodeJwt(t).payload);
// { sub: '1234567890', name: 'John Doe', iat: 1516239022 }

Two details people often miss:

1. The UTF-8 step. atob() alone breaks on names like "José" or emoji, because it returns one character per byte. Passing the bytes through TextDecoder fixes that.
2. Padding. Base64URL removes = padding, and some decoders refuse input without it. Add it back until the length is a multiple of 4.

In Node 16+ you can skip the helper: Buffer.from(part, 'base64url').toString('utf8').

Reading the time claims

exp, iat and nbf are seconds since the Unix epoch, not milliseconds:

const { exp } = decodeJwt(token).payload;
const expiresAt = new Date(exp * 1000);
const expired = Date.now() >= exp * 1000;

Forgetting the * 1000 makes every token look like it expired in January 1970. It's one of the most common JWT bugs I've seen in front-end code.

Decoding is not verifying

This is the part that matters. Everything above tells you what a token claims. It doesn't tell you whether the claims are true. Anyone can write this:

const fake = btoa('{"alg":"HS256"}') + '.' + btoa('{"sub":"admin"}') + '.whatever';

Only the signature check proves who issued the token. On the server, always verify with a maintained library (for example jose in Node) and:

• Pin the algorithm you expect. Don't let the token's own alg header pick it, and never accept alg: "none".
• Check exp, nbf, iss and aud. A valid signature on an expired token, or on a token meant for a different service, should still be rejected.
• Don't put secrets in the payload. It's readable by anyone who holds the token. If you need confidentiality, use encrypted JWTs (JWE) or keep the data server-side.

Front-end decoding is fine for UX, like showing a username or warning before a session expires. It is never an authorization decision.

A note on pasting tokens into websites

Production tokens are credentials. Before you paste one into an online decoder, check that it decodes locally in your browser. Open the Network tab and confirm nothing is sent when you paste. I built the JWT decoder on DevKnife to work that way: it's plain client-side JavaScript, much like the snippet above, with the time claims converted to readable dates. You can also just keep the 10-line function in your snippets folder.

TL;DR

• A JWT is base64url(header).base64url(payload).signature.
• Decoding takes about 10 lines: swap the URL-safe characters, add padding, atob, then TextDecoder.
• exp/iat are in seconds.
• Decoded ≠ verified. Verify on the server with a pinned algorithm, and keep secrets out of the payload.