Base64 rewrites arbitrary bytes using only 64 characters that survive any text channel. The alphabet is fixed:
| Index | Characters |
|---|---|
| 0–25 | A–Z |
| 26–51 | a–z |
| 52–61 | 0–9 |
| 62 | + |
| 63 | / |
The mechanism is a regrouping of bits. Three bytes are 24 bits; 24 divides evenly into four 6-bit groups; each 6-bit group is a number from 0 to 63, which indexes the table above. Nothing is compressed, encrypted or hashed — the bits are identical, only the grouping changed.
Encode the three characters Man:
| Step | Value |
|---|---|
| ASCII codes | M = 77, a = 97, n = 110 |
| As bytes | 01001101 01100001 01101110 |
| Regrouped into 6 bits | 010011 010110 000101 101110 |
| As numbers | 19, 22, 5, 46 |
| Alphabet lookup | T, W, F, u |
So Man becomes TWFu. Four characters out for three bytes in, every time.
When the input is not a multiple of three bytes, the final group is incomplete. It is zero-padded up to six bits, and then = characters are appended so the output length stays a multiple of four:
| Input | Bytes | Output | Padding |
|---|---|---|---|
| Man | 3 | TWFu | none |
| Ma | 2 | TWE= | one |
| M | 1 | TQ== | two |
So the number of equals signs tells you the remainder: one means the input length left 2 over, two means it left 1 over, and you will never see three. Padding is only a length marker — some decoders accept its absence.
Output length is ceil(bytes ÷ 3) × 4, which is roughly a third larger than the input:
| Original | Base64 | Increase |
|---|---|---|
| 1 KB | 1.37 KB | +37% |
| 100 KB | 136.7 KB | +37% |
| 1 MB | 1.37 MB | +37% |
The theoretical floor is 33.3%; real figures land nearer 37% once line breaks are counted, since the MIME specification wraps encoded output at 76 characters per line. This is the practical argument against inlining large images as data URIs — you pay a third more bytes, and unlike a separate file the result cannot be cached independently or loaded lazily.
This is the error most developers hit. The browser function btoa operates on bytes, and it treats each character of its input as one byte. Any character above code point 255 — an emoji, an accented letter in some cases, anything in Arabic, Devanagari or Han — makes it throw an InvalidCharacterError.
The cause is a category error rather than a bug: Base64 encodes bytes, and a string is not bytes until you choose an encoding. The fix is to convert the text to UTF-8 first, usually with TextEncoder, then Base64 the resulting byte array. Decoding runs the reverse: Base64 to bytes, then TextDecoder back to text. Skipping that step produces silent corruption of every non-ASCII character.
Base64 appears in email attachments through MIME, in HTTP Basic authentication headers, in data URIs inside CSS and HTML, in PEM-wrapped certificates and keys, and in binary fields inside JSON, which has no byte type of its own.
Because + and / have meaning in URLs and filenames, a second alphabet exists — base64url, defined in RFC 4648, which substitutes - and _ and usually drops the padding. JSON Web Tokens use this variant, which is why a JWT contains dashes and underscores and no equals signs. Feeding base64url into a standard decoder that does not translate those two characters yields garbage or an error.
The single most important point: Base64 is not encryption and provides no security whatsoever. It is a reversible public transformation with no key. Anything Base64-encoded is readable by anyone in one step, so it must never be used to protect a password, token or personal data. Encoded credentials in a Basic auth header are protected by the transport layer, not by Base64.
It is also not a checksum — it will not detect corruption — and it is not compression, since it makes data larger. Very large inputs can exhaust browser memory, because the whole string plus its decoded form must be held at once.
Usually one of three causes: the input was base64url and the decoder expected the standard alphabet, the padding was stripped by a system that trimmed the string, or the original was binary rather than text and there is nothing readable to show.
Generally yes. The correct length is inferable from the character count, and most decoders reconstruct it. Some strict implementations refuse, which is why padding still exists.
To remove an HTTP request, which mattered a great deal before HTTP/2 multiplexing. For small icons it can still help; for anything sizeable the 37% overhead and the loss of separate caching outweigh the saved request.
No. Encoding and decoding happen in your browser and nothing you paste is transmitted or logged.
" }, "age-calculator": { "title": "Age Calculator — Exact Years, Months and Days, and Why Tools Disagree", "description": "Work out your age in years, months, days and total days from a date of birth, with the borrow algorithm shown, plus the month-end and leap-year edge cases that make calculators differ.", "keywords": "age calculator, exact age in days, age from date of birth, leap year birthday, how many days have i lived, month end date arithmetic", "article": "Calendar age is not a subtraction of two numbers, because months have unequal lengths. The standard method is a borrow algorithm, the same idea as long subtraction:
days = D2 − D1 ; months = M2 − M1 ; years = Y2 − Y1
If days is negative, add the number of days in the month before the target date and reduce months by one. If months is then negative, add 12 and reduce years by one.
That ordering matters. Borrowing days first, then months, gives the answer people expect; doing it in the other order produces off-by-one results near month boundaries.
Date of birth 15 March 1990, measured on 28 August 2026:
| Component | Calculation | Result |
|---|---|---|
| Days | 28 − 15 | 13 |
| Months | 8 − 3 | 5 |
| Years | 2026 − 1990 | 36 |
No borrowing was needed, so the age is 36 years, 5 months and 13 days. The total-days figure is computed separately, because it cannot be derived from that triple:
| Segment | Days |
|---|---|
| 15 Mar 1990 to 15 Mar 2026 — 36 × 365 | 13,140 |
| Leap days in that span (1992, 1996, 2000, 2004, 2008, 2012, 2016, 2020, 2024) | 9 |
| 15 Mar 2026 to 28 Aug 2026 | 166 |
| Total lived | 13,315 |
Because the total-days count runs independently of the calendar, several round numbers arrive on ordinary weekdays:
| Milestone | Approximate age |
|---|---|
| 1,000 days | 2 years 8 months |
| 10,000 days | 27 years 4 months |
| 1 billion seconds | 31 years 8 months |
| 20,000 days | 54 years 9 months |
| 30,000 days | 82 years 1 month |
A year is a leap year if it is divisible by 4, except century years, which must also be divisible by 400. So 1900 was not a leap year and 2000 was. This is why any calculator that simply divides by 365.25 drifts: the true mean Gregorian year is 365.2425 days, and the 400-year cycle contains 97 leap days, not 100.
This is not sloppiness — the question is genuinely underdetermined at month ends. Take 31 January plus one month. Is the result 28 February, because February has no 31st and the day clamps to the last valid one? Or 3 March, because 31 days were added? Reputable date libraries disagree, and both behaviours are documented as correct within their own conventions.
The same ambiguity runs backwards. From 31 January to 1 March, is the elapsed time one month and one day, or 29 days? Counting whole months first gives the former; counting days gives the latter. A tool is only wrong if it is inconsistent with itself.
Two more sources of disagreement: whether the end date counts as a full day, and time zones. If your birth date is stored as midnight UTC and read in a zone behind UTC, the displayed date can shift by one day, which changes the answer by a day near midnight.
Dates before the Gregorian reform are ambiguous rather than merely old. Catholic Europe switched in October 1582; Britain and its colonies switched in September 1752, skipping eleven days so that 2 September was followed by 14 September; Russia switched in 1918 and Greece in 1923. A date recorded in a parish register from 1700 may be Julian, and no calculator can tell which without knowing the place. For genealogy, treat anything before the local switch as approximate.
There are also cultural systems that do not match this arithmetic at all. Korea historically counted a newborn as one year old and added a year at New Year rather than on the birthday, so a person could be two at a few days old. That reckoning was formally set aside in favour of international age in June 2023, but you will still meet both numbers in older documents.
Chronological age is a count of days, nothing more. It is not biological age, and it does not predict health, fitness or life expectancy for any individual — those depend on factors this tool has no access to. Any medical or fitness formula that takes age as an input, including target heart-rate ranges and BMI-for-age percentiles, is a population approximation and no substitute for a clinician.
Note too that some legal and financial contexts do not use the age you would calculate here. Several insurers price on age nearest birthday, which rounds up for anyone past the halfway point, so your quoted age can be one higher than your real one. Tax and pension thresholds sometimes use age at the end of a tax year instead.
Mathematically your age increments on 1 March in non-leap years, because 29 February does not exist to be reached. Legally it varies by jurisdiction — some define the birthday as 28 February and some as 1 March, which occasionally matters for a document that must be signed at exactly 18.
Leap days. Over 36 years there are typically nine of them, so the total is nine days higher than the naive product. Over a century the gap is about 24 days.
Yes, and it is deterministic — the Gregorian calendar repeats on a 400-year cycle, so the weekday for any date follows from the date alone. It has no bearing on anything beyond curiosity.
No. The calculation runs in your browser and the date you enter is never transmitted or saved.
" }, "password-generator": { "title": "Password Generator — Entropy in Bits, and What NIST Now Recommends", "description": "Generate random passwords in your browser, with the entropy formula, a cracking-time table, why a 16-character password beats a complex 8-character one, and why forced complexity rules were dropped.", "keywords": "password generator, password entropy bits, how long should a password be, diceware passphrase, crypto getRandomValues, nist password guidelines", "article": "Password strength is measured in bits of entropy, and for a randomly generated password it is exact:
bits = length × log2(alphabet size)
Each bit doubles the search space. Adding one character to a 95-symbol password adds about 6.6 bits, which multiplies the work by 95. Here is what each alphabet buys per character:
| Alphabet | Size | Bits per character |
|---|---|---|
| Lowercase only | 26 | 4.70 |
| Upper and lower | 52 | 5.70 |
| Alphanumeric | 62 | 5.95 |
| All printable ASCII | 95 | 6.55 |
| Length | 26 chars | 62 chars | 95 chars |
|---|---|---|---|
| 8 | 37.6 bits | 47.6 bits | 52.4 bits |
| 12 | 56.4 bits | 71.5 bits | 78.7 bits |
| 16 | 75.2 bits | 95.3 bits | 104.9 bits |
| 20 | 94.0 bits | 119.1 bits | 131.1 bits |
Assume an offline attack — the attacker has stolen a database and is guessing locally at a trillion candidates per second, which is realistic for a GPU rig against a fast, badly chosen hash. On average half the space must be searched.
| Password | Entropy | Average time to crack |
|---|---|---|
| 8 random printable ASCII | 52.4 bits | about 49 minutes |
| 12 random printable ASCII | 78.7 bits | about 6,000 years |
| 16 random printable ASCII | 104.9 bits | about 640 billion years |
The lesson is the shape of the curve, not the headline numbers. Eight characters is finished within a working day even with every symbol class included. Sixteen is not a matter of waiting for faster hardware — the gap is around fifteen orders of magnitude. Length dominates complexity. A random 16-character lowercase password (75.2 bits) is far stronger than a random 8-character password using every symbol on the keyboard (52.4 bits).
The rule most of us were trained on — one uppercase, one number, one symbol, changed every ninety days — is no longer the recommendation of the body that popularised it. The 2017 revision of the United States NIST digital identity guidelines removed mandatory composition rules and removed routine expiry, and advises checking new passwords against lists of known-breached ones instead.
The reasoning is behavioural. Forced rules do not produce random passwords; they produce predictable transformations of a memorable word. Capital at the front, digit and exclamation mark at the end, a becomes @, o becomes 0. Cracking tools have applied those exact substitution rules for two decades, so the entropy added is a fraction of what the rule appears to add. Forced ninety-day rotation makes it worse, because people increment a counter, and a leaked old password predicts the new one.
This also explains why browser strength meters mislead. Most score the string in front of them by counting character classes, but strength is a property of how the password was chosen, not how it looks. A meter cannot see that one password came from a cryptographic generator and another came from a birthday.
A word list of 7,776 entries — the Diceware size, five dice rolls per word — gives log2(7776) = 12.9 bits per word:
| Words | Entropy | Roughly equivalent to |
|---|---|---|
| 4 | 51.7 bits | 8 random ASCII characters |
| 6 | 77.5 bits | 12 random ASCII characters |
| 7 | 90.5 bits | 14 random ASCII characters |
So six random words are about as strong as twelve random symbols and enormously easier to remember, which makes a passphrase the right choice for the handful of passwords you must type from memory — your device login and your password manager itself. The critical condition is that the words be chosen randomly. A phrase you invented is not four words of entropy; it is one memory, and quoting a song lyric provides almost none.
This matters more than the character set. This generator draws from the browser cryptographic random source, crypto.getRandomValues, which is seeded by the operating system. The ordinary Math.random is unsuitable: it is fast and statistically fine for shuffling a list, but its internal state can be reconstructed from a short run of outputs, which means a sequence of generated passwords becomes predictable.
There is a second, subtler trap. Mapping a random byte (0–255) onto a 95-character alphabet with a remainder operation biases the first 66 characters upward, because 256 is not a multiple of 95. Correct implementations discard out-of-range values and draw again. The bias is small but it is a real reduction in entropy, and it costs nothing to avoid.
The entropy figures above assume the attacker knows your length and alphabet and is reduced to brute force. That is the correct conservative assumption; secrecy about your character set is not security.
More importantly, a strong password solves exactly one problem — guessing. It does nothing against phishing, where you hand it over willingly; nothing against a keylogger; nothing against a breach that exposes the password in usable form; and nothing against reuse. Reuse is the dominant real-world failure: credential-stuffing attacks replay one leaked pair across hundreds of sites, and a 130-bit password reused on a site that stored it carelessly protects nothing elsewhere. Uniqueness per site matters more than the strength of any single one, which in practice means a password manager, and phishing-resistant second factors or passkeys where they are offered.
Sixteen characters or more for anything stored in a password manager, since you never type it. For the few you must memorise, use a six or seven word random passphrase instead.
Usually legacy input filtering or a fixed database column, and occasionally the alarming sign that the password is being stored in a form where its length matters. A site with a low maximum length is worth treating as untrustworthy with anything you reuse.
No — change them when there is a reason: a breach notification, a shared device, or any suspicion of exposure. Scheduled rotation without cause reliably degrades password quality.
No. Generation happens entirely in your browser using its own random source, and nothing is transmitted, logged or stored. Nothing is kept after you close the page, so copy what you need before leaving.
" }, "word-counter": { "title": "Word and Character Counter — What Counts as a Word, and Why Tools Disagree", "description": "Count words, characters, sentences and reading time, and understand hyphen and emoji edge cases, weighted character limits on X, and why Google truncates titles by pixel width not character count.", "keywords": "word counter, character counter, grapheme cluster length, twitter weighted characters, meta title pixel width, reading speed words per minute", "article": "Every counter has to pick a rule, and the reasonable rules disagree. The common one is to trim the text and split it on runs of whitespace, counting the pieces. That is fast, language-neutral and defensible — and it produces surprises.
Take this sentence:
The state-of-the-art model — trained on 1,000,000 documents — did not converge.
| Rule | Count | Why |
|---|---|---|
| Split on whitespace | 12 | Both bare em-dashes become tokens of their own |
| Whitespace, ignoring punctuation-only tokens | 10 | The two dashes are discarded |
| Treat hyphenated compounds as separate words | 13 | state-of-the-art splits into four |
All three answers are correct under their own convention. This is the whole reason a word processor, a submission portal and an online counter can each give you a different number for the same paragraph — and why an essay limit of 2,000 words is best treated as approximate rather than exact.
Other cases that move the number: a number written as 1,000,000 is one token but three if commas are treated as separators; an em-dash used without surrounding spaces joins two words into one token; a URL is one token no matter how long; and in Chinese, Japanese and Thai there are no spaces at all, so whitespace splitting reports a handful of words for a full page of text.
Most people expect one number and there are genuinely three, because a character can mean a storage unit, a Unicode code point, or a thing a reader perceives as one symbol:
| Text | UTF-16 units | Code points | Perceived characters |
|---|---|---|---|
| hello | 5 | 5 | 5 |
| café written with a combining accent | 5 | 5 | 4 |
| A single thumbs-up emoji | 2 | 1 | 1 |
| A four-person family emoji | 11 | 7 | 1 |
| A flag emoji | 4 | 2 | 1 |
The naive length of a string in most programming languages is the first column, which is why a database field of 20 characters can reject a nine-emoji nickname. The number a human would give is the last column, and getting it requires grapheme-cluster segmentation rather than counting.
| Where | Limit | Counting rule |
|---|---|---|
| X posts | 280 | Weighted — Latin and most European text counts 1, but CJK and several other ranges count 2, so a Japanese post caps near 140 |
| Instagram caption | 2,200 | Only the first line or two shows before the More link |
| SMS, single segment | 160 | 7-bit GSM alphabet; one non-GSM character switches the whole message to 70 per segment |
| Meta title | about 50–60 | Truncated by pixel width, not characters |
| Meta description | about 150–160 | Also pixel-based, and frequently rewritten entirely |
Two of those deserve expansion. The SMS rule catches people out constantly: typing one curly apostrophe or one emoji into a 160-character message can silently split it into two billed segments of 70. And the SEO figures are a proxy, not a rule. Search results are truncated when the rendered string exceeds an available width in pixels, so a title of narrow letters survives longer than one full of capital W and M. A 55-character title in wide characters can be cut while a 62-character title in narrow ones is not. Treat 60 as a guideline and check how the actual string looks.
The estimate is simply minutes = words ÷ reading speed. The speed is the contested part. A 2019 meta-analysis of reading-rate studies put average silent reading of English non-fiction at roughly 238 words per minute, with fiction somewhat faster; most publishers use 200 to 250.
| Words | At 200 wpm | At 238 wpm | At 300 wpm |
|---|---|---|---|
| 500 | 2.5 min | 2.1 min | 1.7 min |
| 1,200 | 6.0 min | 5.0 min | 4.0 min |
| 3,000 | 15.0 min | 12.6 min | 10.0 min |
The spread across that table is the honest error bar. Speaking is much slower — a presenter delivers roughly 130 to 150 words per minute, so a five-minute talk is about 700 words, not 1,200.
Sentence counting normally splits on a full stop, question mark or exclamation mark. That over-counts on abbreviations such as Dr. and e.g., on decimals such as 3.14, on ellipses, and on initials in a name; it under-counts when a writer uses semicolons or line breaks instead of terminal punctuation. Paragraph counting depends on whether a single line break or a blank line is treated as the separator, which is why pasting from a PDF can report every line as its own paragraph.
A word count measures length and nothing else. It cannot see whether a sentence is clear, whether an argument holds, or whether a paragraph earns its place — and a longer count is not a better piece of writing. Readability scores such as Flesch-Kincaid, where they are offered, are formulas over sentence and syllable length; they reward short words, which is not the same as rewarding good prose.
On the search side, there is no minimum word count that ranks and no keyword-density figure to hit. Density targets are an artefact of tools from an earlier era of search, and writing to satisfy one reliably makes text worse. Length should follow from what the topic needs.
Because it applies a different rule to hyphens, dashes and punctuation-only tokens. For a hard limit, count with whatever tool the person enforcing the limit uses, and leave a margin of a few per cent.
Weighted counting. Characters outside the Latin and common European ranges count double, and a shortened link is counted as a fixed length regardless of the URL you pasted.
It depends on who is asking. Publishers pricing by characters usually exclude spaces; platform limits and database fields include them. Both figures are shown for that reason.
No. All counting happens in your browser, and nothing you paste is transmitted, logged or saved.
" }, "bmi-calculator": { "title": "BMI Calculator — The Formula, the 1832 Origin, and What It Cannot Tell You", "description": "Calculate BMI in metric or imperial units, with the formula worked through, healthy weight ranges by height, the different thresholds used for Asian populations, and honest limits.", "keywords": "bmi calculator, body mass index formula, healthy weight range by height, waist to height ratio, asian bmi cut off, quetelet index", "article": "Body Mass Index is one division:
BMI = weight in kilograms ÷ (height in metres)²
In imperial units the same relationship needs a conversion constant:
BMI = 703 × weight in pounds ÷ (height in inches)²
Someone 1.75 m tall weighing 78 kg:
| Step | Value |
|---|---|
| Height squared | 1.75 × 1.75 = 3.0625 |
| Divide weight by it | 78 ÷ 3.0625 = 25.47 |
| BMI | 25.5 |
The same person in imperial units — 69 inches and 172 pounds — gives 703 × 172 ÷ 4761 = 25.40. The small gap is rounding in the unit conversion, not a different method.
That result sits just over the line into the overweight band, which illustrates something important: at 76.6 kg the same person is classified normal, and at 76.7 kg overweight. The categories are administrative cut-points on a continuous scale, and nothing about a body changes across them.
| BMI | WHO category |
|---|---|
| Below 18.5 | Underweight |
| 18.5 to 24.9 | Normal range |
| 25.0 to 29.9 | Overweight |
| 30.0 to 34.9 | Obesity class I |
| 35.0 to 39.9 | Obesity class II |
| 40.0 and above | Obesity class III |
Because the categories are ratios, they translate into a weight band for any height. The figures below are the 18.5 and 25.0 boundaries:
| Height | 18.5 (kg) | 25.0 (kg) |
|---|---|---|
| 1.55 m | 44.4 | 60.1 |
| 1.60 m | 47.4 | 64.0 |
| 1.70 m | 53.5 | 72.3 |
| 1.75 m | 56.7 | 76.6 |
| 1.80 m | 59.9 | 81.0 |
| 1.90 m | 66.8 | 90.3 |
This is the part that explains most of its problems. The ratio was devised around 1832 by Adolphe Quetelet, a Belgian astronomer and statistician, as part of his work on the average man. He was describing populations, largely of European men, and looking for the mathematical regularities of a group. He was not proposing a way to assess an individual patient, and no health outcome data existed to validate it against.
The name body mass index was attached much later, by the physiologist Ancel Keys in 1972, who tested several height-weight ratios and found Quetelet's the best available proxy for body fatness in population studies — while stating plainly that it was suited to groups rather than individual diagnosis. In 2023 the American Medical Association adopted a policy formally acknowledging BMI as an imperfect measure that should be used alongside other assessments rather than on its own.
So a number designed for demographic statistics in the nineteenth century became a clinical shorthand in the twentieth, and that migration is the source of the mismatch people notice in their own results.
Dividing by height squared has a known bias. Mass scales with volume, which grows closer to the cube of a linear dimension, while the divisor grows with the square. The consequence is systematic: BMI reads high for tall people and low for short people of identical build. This is why an alternative using an exponent nearer 2.5 has been proposed — the square was chosen because it happened to fit mid-century European survey data reasonably well, not because it reflects how bodies scale.
Cardiometabolic risk rises at lower BMI values in several populations, particularly South and East Asian, because for a given BMI the average proportion of body fat and of visceral fat is higher. A WHO expert consultation in 2004 recognised this, and many countries now use lower action points — commonly around 23 for increased risk and 25 for high risk, rather than 25 and 30. If you are using BMI at all, use the thresholds your own health service publishes.
BMI does not measure body fat. It measures nothing but mass against height, and it cannot distinguish between:
It is not valid as presented for children and teenagers, who need age-and-sex percentile charts because normal body composition changes throughout growth; during pregnancy; for older adults, where height loss from spinal compression inflates the figure while muscle loss hides fat gain; or for anyone with a limb difference or a condition that alters body composition.
A single better companion measure exists and costs nothing: waist circumference, or waist divided by height. Keeping waist below half your height is a widely used rule of thumb, and it captures central adiposity — the part that carries most of the risk — which BMI is blind to.
This is general information, not medical advice. BMI is a screening ratio, not a diagnosis, and no number here can tell you whether you are healthy. Blood pressure, blood lipids, blood glucose, fitness, sleep and family history all matter, and interpreting them together is a job for a doctor who can examine you.
For you, effectively yes. Muscle is denser than fat, so a muscular build inflates BMI without the associated risk. Waist measurement and body-fat estimation are far more informative in that case.
No — it is useful for what it was built for. Across large groups it tracks average risk well and it is cheap and reproducible, which is why epidemiology still uses it. The error is treating a population statistic as a verdict on one person.
Waist-to-height ratio is the most informative measure you can take with a tape measure. Beyond that, trends in your own numbers over months are more meaningful than any single reading against a threshold.
Not directly. Compute it if you like, but interpretation requires a paediatric percentile chart for age and sex, and that reading belongs with a paediatrician.
No. The calculation happens in your browser and the figures you enter are never transmitted or saved.
" }, "bill-splitter": { "title": "Bill Splitter — Even Splits, Itemised Shares and the Missing-Cent Problem", "description": "Split a restaurant bill fairly, with worked examples for even and itemised splits, proportional tax and tip, the one-multiplier shortcut, and how to handle leftover cents.", "keywords": "bill splitter, split the check, itemised bill split, tip before or after tax, penny rounding split, share restaurant bill fairly", "article": "The arithmetic looks trivial:
each person = (subtotal + tax + tip) ÷ number of people
The complication is that money has two decimal places and division usually does not. A total of 87.43 between three people gives 29.14333…, and if everybody pays 29.14 the table is one cent short.
The fix is to work in whole cents and distribute the remainder rather than rounding each share independently:
| Step | Value |
|---|---|
| Total in cents | 8,743 |
| Divide by 3 | 2,914 with remainder 1 |
| Result | One person pays 29.15, two pay 29.14 |
Rounding each share up instead produces 29.15 × 3 = 87.45, a two-cent overpayment. Rounding each down leaves the payer short. Remainder distribution is the only method that always reconciles exactly, and it is what a correct splitter does silently.
When people ordered different things, the fair approach is that each pays their own items plus a proportional share of tax and tip — not an equal share of them, because tax and tip both scale with what was ordered.
Three diners:
| Person | Items | Share of subtotal |
|---|---|---|
| A | 24.00 | 32.43% |
| B | 18.50 | 25.00% |
| C | 31.50 | 42.57% |
| Subtotal | 74.00 | 100% |
Tax at 8.5% is 6.29. Tip at 18% of the pre-tax subtotal is 13.32. The grand total is 93.61.
There is a shortcut that avoids computing three percentages. Divide the grand total by the subtotal once to get a single multiplier, then apply it to each person:
multiplier = 93.61 ÷ 74.00 = 1.265
| Person | Items × 1.265 | Pays |
|---|---|---|
| A | 24.00 × 1.265 | 30.36 |
| B | 18.50 × 1.265 | 23.40 |
| C | 31.50 × 1.265 | 39.85 |
| Total | 93.61 |
It reconciles to the cent here, but check it every time — when it does not, the difference is a cent or two and is settled by the remainder rule above.
On the same bill the choice is not trivial:
| Basis | 18% tip | Grand total |
|---|---|---|
| Pre-tax subtotal (74.00) | 13.32 | 93.61 |
| Post-tax total (80.29) | 14.45 | 94.74 |
Just over a dollar apart, and about 8% more tip. Tipping on the pre-tax amount is the traditional convention, on the reasoning that you are rewarding service rather than the tax authority. Card terminals increasingly compute their suggestions on the post-tax figure, which quietly raises every percentage on the screen.
This is where splitters usually break down, because it is a question about the table rather than about arithmetic. A shared appetiser has no owner. Three workable conventions:
The one case where an even split is clearly wrong is alcohol. Drinks are frequently the largest and most unevenly distributed part of a bill, and in many places they are taxed at a different rate, so a non-drinker paying an even share can be subsidising a substantial amount.
Worth knowing if the suggested figures ever feel high: the standard tip is not a fixed custom. In the middle of the twentieth century 10% was normal in the United States; 15% became the default by the 1980s; 18 to 20% is the common floor now, and card terminals often present 20, 25 and 30. Part of that drift is straightforward anchoring — a default option shifts the average choice toward it, and the presets are set by the merchant, not by any standard.
The convention is also strictly local. Service is frequently included in the bill across much of continental Europe, where a small round-up is the norm rather than a percentage. In Japan tipping is not customary and can cause confusion. And a mandatory service charge is not a tip at all — it is a line item on the bill, and whether it reaches the staff depends entirely on the establishment, so it is worth asking before adding a further amount on top.
A splitter can only divide the numbers you give it. It does not know who ordered what, cannot see a discount that applied to one dish, cannot apply the different tax rates that some jurisdictions levy on alcohol or prepared food separately, and cannot judge whether an even split is the socially correct answer.
Currency rounding is a real edge case. Where the smallest coin is larger than the smallest accounting unit — Canada after the withdrawal of the penny, Switzerland with its five-centime coin — cash totals round to the nearest available coin while card payments do not, so the cash and card versions of the same split differ by a few cents.
Itemise. Take their drink out, apply the multiplier method to everyone including them, and the tax and tip fall out proportionally without anyone having to negotiate.
Because the total does not divide exactly. Distributing the leftover cent to one payer is the only way the payments sum to the bill; the alternative is for the table to be short or over.
It is a convention rather than a rule, and it has the odd property that a bottle of wine attracts more tip than a plate of food requiring more work. Some diners tip per person or per course for that reason. The tool will compute whatever basis you prefer.
No. Every figure stays in your browser and nothing is transmitted or saved.
" }, "break-even": { "title": "Break-Even Calculator — Contribution Margin, Sensitivity and Operating Leverage", "description": "Find the units and revenue you need to break even, with a fully worked example, a sensitivity table, margin of safety, operating leverage, and the assumptions that make the number misleading.", "keywords": "break even calculator, contribution margin, break even units formula, margin of safety, operating leverage, step fixed costs", "article": "Break-even is where total revenue equals total cost, and it rests on one intermediate figure that matters more than the answer itself — contribution margin, the amount each sale contributes toward covering fixed costs.
contribution margin = price − variable cost per unitbreak-even units = fixed costs ÷ contribution marginbreak-even revenue = fixed costs ÷ (contribution margin ÷ price)
The distinction that trips people up is which costs are which. Fixed costs do not move with volume: rent, salaried wages, insurance, software subscriptions. Variable costs occur only because a unit was sold: materials, packaging, payment-processing fees, per-order shipping.
A small coffee shop:
| Item | Amount |
|---|---|
| Rent | 3,200 / month |
| Wages (salaried) | 2,400 / month |
| Insurance, software, utilities | 900 / month |
| Fixed costs | 6,500 / month |
| Selling price per cup | 4.20 |
| Variable cost per cup (beans, milk, cup, card fee) | 1.35 |
| Step | Calculation | Result |
|---|---|---|
| Contribution margin | 4.20 − 1.35 | 2.85 per cup |
| Margin ratio | 2.85 ÷ 4.20 | 67.9% |
| Break-even units | 6,500 ÷ 2.85 | 2,281 cups / month |
| Break-even revenue | 2,281 × 4.20 | 9,580 |
| Over 26 trading days | 2,281 ÷ 26 | 88 cups / day |
That last line is the one worth converting to. A monthly figure is abstract; 88 cups a day is a claim about the business you can actually judge as plausible or not.
Break-even is more sensitive to price and variable cost than to fixed cost, because those two change the divisor:
| Change | New margin | Break-even units | Shift |
|---|---|---|---|
| Baseline | 2.85 | 2,281 | — |
| Price up 30 cents | 3.15 | 2,064 | −9.5% |
| Price down 30 cents | 2.55 | 2,549 | +11.8% |
| Variable cost up 25 cents | 2.60 | 2,500 | +9.6% |
| Fixed costs up 500 | 2.85 | 2,456 | +7.7% |
A 7% price increase cuts the required volume by nearly 10%. This is why margin work usually beats cost-cutting: the price line has leverage that the rent line does not.
Breaking even means earning nothing. To find the volume for a profit you actually want, add it to fixed costs:
units for target profit = (fixed costs + target profit) ÷ contribution margin
For 2,000 of monthly profit: (6,500 + 2,000) ÷ 2.85 = 2,982 cups, or 115 a day. That is 31% more volume than break-even, and it is the number a plan should be built around.
Two derived figures tell you how fragile the position is. Suppose actual sales are 3,000 cups.
margin of safety = (3,000 − 2,281) ÷ 3,000 = 24% — sales can fall by roughly a quarter before losses begin.
operating leverage = total contribution ÷ profit = 8,550 ÷ 2,050 = 4.17
That multiplier applies in both directions. A 10% rise in sales lifts profit by about 42% — 3,300 cups yields 9,405 of contribution and 2,905 of profit. A 10% fall cuts profit by the same proportion. High fixed costs and high margins produce high leverage, which is excellent above break-even and brutal below it.
Break-even is a straight-line model, and the line bends in at least five places.
Fixed costs are not fixed; they step. At some volume you need a second member of staff, a bigger machine, more space. Costs jump by a discrete amount and the break-even point resets. Plotted honestly, the cost line is a staircase, and a business can be profitable at 2,500 units and lossmaking at 3,000.
Variable cost per unit is not constant. Volume brings supplier discounts, which lowers it, while overtime and rush shipping raise it.
Price is not constant. Reaching higher volume often requires discounting or promotion, so the extra units arrive at a lower margin than the ones in your model.
The owner is usually missing. This is the most common and most expensive error in a small-business plan. If the founder works full-time and takes no salary, their labour has been valued at zero and the break-even figure is fiction. Put a market wage for yourself into fixed costs before believing any of the output.
Profit is not cash. Break-even is an accounting concept and ignores timing. A business past break-even on paper can still fail, because inventory was paid for in March and the invoice settles in June. Break-even tells you nothing about the working capital needed to get there, and cash-flow projection is a separate exercise you still have to do.
Multiple products add a further wrinkle: with more than one item you must use a weighted-average contribution margin based on the sales mix, and the break-even point moves whenever that mix shifts — even at constant total revenue. Selling the same money in low-margin items instead of high-margin ones can push you back below break-even with no visible change in the top line.
This is general business information, not financial or accounting advice. Figures for a real plan should be reviewed with an accountant who can see your actual numbers and local tax position.
Not usually. Break-even is normally computed pre-tax, since income tax applies to profit and there is none at break-even. For a target-profit figure, decide whether the target is before or after tax and be consistent — an after-tax target must be grossed up by your rate.
No. It is not losing money at that moment, at that cost structure, with that mix. Margin of safety tells you how much room there is, and the answer is often less than owners expect.
Split it. A phone line with a standing charge plus per-minute usage is fixed on the standing charge and variable on the usage. Guessing wrong here distorts the margin, which is the figure everything else depends on.
No. Everything you enter stays in your browser and nothing is transmitted or saved.
" }, "color-converter": { "title": "Colour Converter — HEX, RGB, HSL and CMYK Worked Through One Colour", "description": "Convert between HEX, RGB, HSL and CMYK with every formula shown on a single worked example, plus contrast ratios, why HSL lightness is not perceptual, and why printed CMYK never matches.", "keywords": "hex to rgb, rgb to hsl formula, rgb to cmyk conversion, relative luminance contrast ratio, oklch colour space, out of gamut cmyk", "article": "Take #FF5733 and convert it every way, showing the arithmetic rather than just the result.
HEX to RGB is a base change. Each pair of hex digits is one byte from 0 to 255:
| Pair | Hex | Decimal |
|---|---|---|
| Red | FF | 255 |
| Green | 57 | 5 × 16 + 7 = 87 |
| Blue | 33 | 3 × 16 + 3 = 51 |
Three-digit codes are shorthand in which each digit is doubled, so #F53 means #FF5533 — a different colour from this one, which is a common source of a slightly-wrong brand shade.
First scale each channel to the range 0 to 1: R = 1.0, G = 0.3412, B = 0.2. Then
L = (max + min) ÷ 2S = delta ÷ (2 − max − min) when L is above 0.5H = 60 × ((G − B) ÷ delta) when red is the maximum channel
| Step | Calculation | Result |
|---|---|---|
| max, min, delta | 1.0, 0.2, 0.8 | — |
| Lightness | (1.0 + 0.2) ÷ 2 | 60% |
| Saturation | 0.8 ÷ (2 − 1.0 − 0.2) | 100% |
| Hue | 60 × (0.3412 − 0.2) ÷ 0.8 | 11 degrees |
So #FF5733 is rgb(255, 87, 51) and hsl(11, 100%, 60%).
K = 1 − max(R, G, B), then each ink is (1 − channel − K) ÷ (1 − K):
| Ink | Calculation | Result |
|---|---|---|
| Key (black) | 1 − 1.0 | 0% |
| Cyan | (1 − 1.0 − 0) ÷ 1 | 0% |
| Magenta | (1 − 0.3412) ÷ 1 | 66% |
| Yellow | (1 − 0.2) ÷ 1 | 80% |
This is the most important caveat on any colour converter, and most omit it. The formula above is pure arithmetic with no knowledge of ink, paper or press. Real conversion is a device transform driven by an ICC profile, because the same nominal 66% magenta lays down differently on coated stock than on newsprint, and different presses have different achievable ranges.
Worse, this particular colour is outside the printable range for most four-colour presses. Saturated oranges, vivid blue-greens and pure greens simply cannot be mixed from CMY inks at screen intensity. When you send it to print, the profile substitutes the nearest reachable colour, which is why a bright orange on screen returns as a duller brick tone. No converter can prevent that; only choosing an in-gamut colour, or a spot ink, can.
The second thing worth knowing. HSL is convenient because you can lighten a colour by raising one number, but its lightness axis is a geometric midpoint, not a perceptual one. Compare two colours that HSL says are equally light:
| Colour | HSL | Relative luminance |
|---|---|---|
| Pure yellow | hsl(60, 100%, 50%) | 0.928 |
| Pure blue | hsl(240, 100%, 50%) | 0.072 |
Both report 50% lightness; one is nearly thirteen times brighter than the other. The reason is that the eye is far more sensitive to green than to blue, which the luminance coefficients capture — L = 0.2126R + 0.7152G + 0.0722B on gamma-decoded channels — and HSL ignores entirely. So a palette built by holding HSL lightness constant will look wildly uneven.
This also explains why naive blending misfires. sRGB values are gamma-encoded, so averaging two hex codes does not average their light. The midpoint of black and white in sRGB arithmetic is #808080, which emits only about 21% of white light rather than 50%, and interpolating between complementary hues through sRGB passes through a muddy grey.
The modern answer is a perceptually uniform space. CSS now supports oklch and lab, where the lightness value does correspond to perceived lightness, so two colours at the same L genuinely look equally light and gradients interpolate without dead zones. If you are building a design system, defining your palette in oklch and converting to hex for legacy output solves the evenness problem at the source.
Contrast ratio uses the same luminance figure:
ratio = (lighter + 0.05) ÷ (darker + 0.05)
For our colour, the relative luminance works out to 0.283:
| Pairing | Ratio | WCAG result |
|---|---|---|
| #FF5733 on white | 3.15 : 1 | Fails AA body text; passes large text and UI components |
| #FF5733 on black | 6.66 : 1 | Passes AA; just short of AAA |
| Black on white | 21 : 1 | The maximum possible |
The thresholds are 4.5 to 1 for normal text, 3 to 1 for large text and interface elements, and 7 to 1 for the stricter AAA level. A vivid brand colour that fails on white is extremely common — the usual fix is to keep it for large headings, buttons and accents, and use a darkened variant for body copy.
Conversions between HEX, RGB and HSL are exact and lossless, because all three describe the same sRGB coordinates. Everything else is an approximation:
Almost always out-of-gamut clipping. Check the colour against a CMYK profile for the actual paper and press before approving artwork, and expect saturated oranges, greens and blues to shift most.
In theory they can; in practice equal parts of all three make a muddy brown, use three times the ink, and soak the paper. A dedicated black ink gives crisp text and cheaper coverage.
oklch if your targets support it, because equal lightness values look equal and tints and shades come out evenly spaced. Convert to hex for anywhere that needs it.
No. Every conversion runs in your browser and nothing you enter is transmitted or saved.
" }, "compound-interest": { "title": "Compound Interest Calculator — Frequency, APY, Fees and the Inflation Correction", "description": "Project growth with the compound interest formula worked step by step, compare compounding frequencies and APY, test the rule of 72, and see what fees and inflation remove from the result.", "keywords": "compound interest calculator, apr vs apy, compounding frequency comparison, rule of 72 accuracy, real vs nominal return, fee drag on investments", "article": "A = P × (1 + r ÷ n) ^ (n × t)
where P is the starting amount, r the annual nominal rate as a decimal, n the number of compounding periods per year, and t the number of years. If you add money regularly, a second term is needed for the stream of deposits:
future value of deposits = PMT × ((1 + i) ^ N − 1) ÷ i
with i the rate per period and N the number of periods. The two results are added.
10,000 invested for 20 years at 7% nominal, compounded annually:
| Step | Value |
|---|---|
| Growth factor | 1.07 ^ 20 = 3.8697 |
| Final balance | 10,000 × 3.8697 = 38,697 |
| Of which interest | 28,697 |
Now add 500 a month at the same rate compounded monthly. The rate per period is 0.0058333 and there are 240 periods:
| Component | Value |
|---|---|
| Initial 10,000 grown monthly | 40,375 |
| Annuity factor — (1.0058333 ^ 240 − 1) ÷ 0.0058333 | 520.71 |
| 500 × 520.71 | 260,355 |
| Total | 300,730 |
| Total paid in | 130,000 |
| Growth | 170,730 — about 57% of the balance |
Less than the marketing suggests. Same 10,000, same 7%, same 20 years:
| Compounded | Effective annual rate | Final balance |
|---|---|---|
| Annually | 7.000% | 38,697 |
| Semi-annually | 7.123% | 39,593 |
| Quarterly | 7.186% | 40,064 |
| Monthly | 7.229% | 40,375 |
| Daily | 7.250% | 40,532 |
| Continuously | 7.251% | 40,552 |
The whole span from annual to continuous is 4.8%, and almost all of it is captured by the time you reach monthly. Daily compounding is a rounding difference. Rate and time do the work; frequency is a detail.
That effective-rate column is the difference between APR and APY. APR is the nominal rate before compounding; APY is what you actually earn once compounding is applied. A 7% APR compounded monthly is a 7.229% APY, which is why a savings account advertising one number and a loan advertising the other are not directly comparable. Always compare like with like.
Dividing 72 by the percentage rate estimates the doubling time. It is a good shortcut in a narrow band:
| Rate | Rule of 72 | Exact | Error |
|---|---|---|---|
| 2% | 36.0 years | 35.0 | +2.9% |
| 7% | 10.3 years | 10.24 | +0.4% |
| 8% | 9.0 years | 9.01 | −0.1% |
| 20% | 3.6 years | 3.80 | −5.3% |
The exact figure is ln(2) ÷ ln(1 + r). The rule is calibrated near 8% and drifts either side; for continuous compounding the correct numerator is 69.3, and 72 was chosen historically because it divides neatly by 2, 3, 4, 6, 8, 9 and 12.
Two deductions turn an impressive projection into a realistic one, and most calculators show neither.
Fees compound too. A 1% annual charge does not cost 1%; it removes a percentage point from the growth rate for every year of the run. On the original example, 7% becomes 6%:
| Net rate | Balance after 20 years |
|---|---|
| 7.0% | 38,697 |
| 6.0% | 32,071 |
One percentage point of fee removed 6,626 — about 17% of the final balance, from a charge that reads as trivial on a statement. Over 30 years the same gap costs around 24%.
Inflation removes more. The 300,730 figure above is in future currency. With inflation at 3%, prices rise by a factor of 1.03 ^ 20 = 1.806, so that balance buys what 166,490 buys today. The real rate is not 7% minus 3% but 1.07 ÷ 1.03 − 1 = 3.88%. More than 40% of the apparent gain is the currency shrinking rather than the portfolio growing.
The practical fix is to run the projection in real terms — use an inflation-adjusted rate and read the answer as today money — or to run both and quote the pair. A projection stated only in nominal terms flatters itself.
You will see compound interest described as the eighth wonder of the world, or the most powerful force in the universe, attributed to Albert Einstein. There is no evidence he said either. Neither line appears in his writings, letters or recorded remarks, and the attributions surface in print decades after his death — most often in advertising for financial products. It is a marketing flourish that acquired a famous name, and it is worth noticing that the claim most often used to sell compounding is itself fabricated. The mathematics needs no celebrity endorsement.
The formula assumes a constant rate, and no investment delivers one. A portfolio averaging 7% arrives at that average through good and bad years, and the order of those years changes the outcome whenever money is being added or withdrawn — the same average return can produce materially different balances. Compound interest models a bank deposit accurately and a stock market only as a smoothed long-run average.
Other omissions to hold in mind: tax on interest, dividends or gains is not modelled, and where it applies annually it reduces the compounding base; contributions held flat in nominal terms shrink in real value each year, so a plan should escalate them with inflation; and the projection assumes you never interrupt the deposits, which real life rarely permits.
This is general information, not financial advice. Any rate entered here is an assumption, not a forecast, and decisions about your own money warrant a qualified adviser who can see your full position.
Whatever you assume, run a lower one beside it. The gap between a 5% and an 8% assumption over 30 years is larger than most people expect, and planning to the optimistic figure is how projections fail. Historical averages are not promises.
Usually APR against APY, or a different compounding basis, or an introductory rate that reverts. Ask for the effective annual yield and the date it changes.
Rarely on its own — see the frequency table, where the whole range is under 5% of the outcome. A meaningfully higher rate or a lower fee matters far more.
No. The projection runs in your browser and nothing you enter is transmitted or saved.
" }, "css-gradient": { "title": "CSS Gradient Generator — Angles, the Grey Dead Zone and Banding Fixes", "description": "Build linear, radial and conic CSS gradients, with the angle convention explained, the gradient-line length formula, why sRGB interpolation muddies colours, and how to kill visible banding.", "keywords": "css gradient generator, linear gradient angle, gradient banding fix, oklch gradient interpolation, conic gradient, animate css gradient", "article": "A linear gradient takes a direction followed by colour stops:
background: linear-gradient(135deg, #6366f1 0%, #ec4899 100%);
The angle convention is the usual first stumble. In CSS, 0deg points upward and angles increase clockwise:
| Angle | Direction | Keyword equivalent |
|---|---|---|
| 0deg | Upward | to top |
| 90deg | Rightward | to right |
| 180deg | Downward | to bottom |
| 135deg | Down and right | to bottom right, on a square |
Two traps live here. Mathematical convention puts 0 to the right and counts anticlockwise, so a gradient translated from a design tool is frequently rotated by 90 degrees. And the keyword to bottom right is not identical to 135deg — the keyword aims the gradient at the actual corner, so its angle changes with the box aspect ratio, while a degree value is fixed.
Useful when you want a stop to land on an exact pixel. For a box of width W and height H at angle A, the gradient line is
length = |W × sin(A)| + |H × cos(A)|
On a 400 by 200 box at 135deg, where sine and cosine are both 0.7071 in magnitude:
| Term | Value |
|---|---|
| 400 × 0.7071 | 282.84 |
| 200 × 0.7071 | 141.42 |
| Gradient line | 424.26 px |
So 50% is 212 pixels along that diagonal, not 200 across the width. Percentages are measured along the gradient line, which is why a stop that looks right on a wide element drifts when the element becomes tall.
Interpolate blue to yellow and the middle turns grey. This is not a browser bug — it is a consequence of averaging gamma-encoded sRGB channels. The numeric midpoint of #0000FF and #FFFF00 is #808080, a dead neutral, because the two colours sit on opposite sides of the colour cube and the straight line between them passes through its centre.
There are three ways out:
linear-gradient(in oklch, blue, yellow) travels around the hue circle instead of through the middle, and the result stays saturated across the whole run. This is the modern fix and it is a one-word change.A related trap: fading to transparent. That keyword expands to fully transparent black, so a white-to-transparent fade can pick up a grey cast in engines that do not premultiply. Writing the explicit rgba(255, 255, 255, 0) removes the ambiguity.
Subtle gradients show visible stripes because each channel has only 256 values. Take a background running from #1a1a2e to #16213e: the blue channel moves from 46 to 62, which is 17 distinct values for the whole width. Spread across 1,200 pixels that gives bands roughly 70 pixels wide — unmissable on a large screen.
| Channel travel | Bands available | Band width over 1,200 px |
|---|---|---|
| 16 values | 17 | 71 px |
| 60 values | 61 | 20 px |
| 200 values | 201 | 6 px |
The practical remedies are to increase the colour distance, to shorten the gradient, to overlay a faint noise texture that dithers the boundaries, or to add intermediate stops so the browser interpolates over shorter runs. Angled gradients band less visibly than perfectly horizontal or vertical ones, because the edges are not aligned with the pixel grid.
Placing two stops at the same position produces a hard edge instead of a blend — linear-gradient(90deg, #6366f1 50%, #ec4899 50%) is two solid halves, and repeating that pattern is how stripes, checkerboards and progress bars are drawn without images.
Radial gradients take a shape and a size, and the sizing keyword matters more than the colours: farthest-corner is the default, while closest-side produces a much tighter falloff. Conic gradients sweep around a centre point, which makes pie charts and colour wheels possible in pure CSS, and combined with repeating-conic-gradient they draw radial stripes.
Older tutorials, and many generators, still emit a stack of prefixed duplicates. That advice is not merely obsolete, it is actively harmful: -webkit-linear-gradient used the old angle convention, where 0deg pointed to the right. Pasting a prefixed line beneath an unprefixed one with the same angle value therefore describes a gradient rotated 90 degrees, and any browser that prefers the prefixed rule renders the wrong thing. Unprefixed gradients have been universally supported for over a decade. Emit one clean declaration.
Gradients are painted, not composited. A transform or an opacity change can be handled by the GPU without repainting; changing a gradient, or animating background-position across a large area, forces a repaint every frame and will drop frames on a big hero section or a low-powered phone.
Gradients are also not interpolatable by default, so a CSS transition between two background-image values snaps rather than blends. The workable patterns are to stack two gradient layers and animate the opacity of the top one, or to register a custom property with @property so its value becomes animatable, or to animate a transform on an oversized gradient element. And if a gradient animates continuously, honour prefers-reduced-motion — moving background colour is a common trigger for people with vestibular sensitivity.
Text over a gradient has varying contrast, and the standard tools check one pair of colours. Test the worst point along the run, not the average, or place a semi-transparent scrim behind the text so the ratio is constant.
Gradients are unreliable in email — desktop Outlook ignores background-image entirely, so a gradient there needs a fallback background colour that is legible on its own. Many browsers omit backgrounds when printing unless the user opts in. And a gradient can never be a substitute for meaning: if it distinguishes one state from another, that state needs a non-visual signal too.
Eight-bit banding. Widen the colour distance, add stops, or dither with a noise overlay — see the table above for how few steps a subtle gradient really has.
Different zero point. Design tools commonly measure from the right and anticlockwise; CSS measures from the top and clockwise.
Not directly. Cross-fade two stacked layers with opacity, which is also the cheaper option to render.
No. The preview and the generated CSS are produced in your browser, and nothing is transmitted or saved.
" }, "json-formatter": { "title": "JSON Formatter and Validator — Every Way Valid JSON Goes Wrong", "description": "Format and validate JSON in your browser, with the six value types, the syntax JSON does not allow, the large-integer precision trap, duplicate keys and prototype pollution explained.", "keywords": "json formatter, json validator, json trailing comma error, json large integer precision, duplicate keys json, jsonc comments tsconfig", "article": "The whole grammar, standardised as RFC 8259 and ECMA-404, permits exactly six kinds of value: object, array, string, number, boolean and null. Keys must be strings in double quotes. That is the entire specification, and almost every error people hit comes from assuming something else is allowed.
| What people write | Why it fails |
|---|---|
| A key without quotes | Keys must be quoted strings, always |
| A string in single quotes | Only double quotes are strings in JSON |
| A comma after the last item | Trailing commas are not permitted |
| A comment on its own line | JSON has no comments at all |
| NaN, Infinity or undefined | None of these are JSON values |
| A date | There is no date type — dates are strings by convention |
| Wrapping the whole thing in a function call | That is JSONP, not JSON |
This fragment contains three separate errors, and most editors report only the first:
{ id: 1, name: two, tags: [a, b,] }
| Position | Problem | Fix |
|---|---|---|
| The keys | Unquoted identifiers | Quote every key |
| The values | Bare words are not strings | Quote every string value |
| After the last array item | Trailing comma | Remove it |
The reason errors cascade like this is that a parser fails at the first byte it cannot account for and reports a character offset, not a diagnosis. A message about an unexpected token at position 2 usually means the problem started earlier — a quote you closed too soon, or an opening brace with no partner.
Two error messages worth recognising on sight. An unexpected token at position 0 often means the file begins with a UTF-8 byte order mark, an invisible three-byte prefix that some Windows editors add; the JSON is otherwise perfect and looks it. And an unexpected end of input means a bracket or brace was never closed, which formatting will locate immediately once the rest parses.
This one silently corrupts data, and it is the most consequential item on the page. JSON numbers have no size limit in the specification, but JavaScript parses every number as a double-precision float. Integers stay exact only up to 2 to the 53rd power minus one, which is 9,007,199,254,740,991.
| Value in the JSON text | Value after parsing in JavaScript |
|---|---|
| 9007199254740992 | 9007199254740992 |
| 9007199254740993 | 9007199254740992 — changed |
| 0.1 plus 0.2 | 0.30000000000000004 |
No error is raised. The number simply comes out different. This is why large-scale APIs that use 64-bit identifiers also send a string version of the same field — the numeric one cannot survive a round trip through a JavaScript client. If you are designing an API, send identifiers, currency amounts and anything else that must be exact as strings, and parse them deliberately.
The specification does not say what should happen when the same key appears twice in one object. In practice most parsers keep the last occurrence, some keep the first, and a few raise an error.
That ambiguity has a security consequence. If a request passes through two components that use different parsers — a gateway that validates and a service that acts — and each resolves duplicates differently, then one document can mean two things. A validator sees the harmless first value while the service acts on the second. The defence is to reject duplicate keys outright rather than to pick a winner.
A related class of bug: a key of __proto__ in JSON is a harmless string as far as parsing goes, but if the parsed object is then merged into an existing object with a naive deep-merge routine, it can alter the prototype chain and change behaviour across an entire application. This is prototype pollution, and it is a real vulnerability class rather than a curiosity. Parsing is safe; careless merging afterwards is not.
JSON strings are sequences of Unicode characters, with escape forms for the double quote, the backslash itself, newline, tab, carriage return, form feed, backspace, and a four-hex-digit numeric form. Characters outside the basic multilingual plane — most emoji, many historic scripts — need two of those numeric escapes forming a surrogate pair. A single unpaired half is technically invalid, and parsers differ on whether they reject it or pass it through as a damaged character, which is a common cause of text that looks fine in one system and broken in the next.
The encoding itself should always be UTF-8. The specification permits it exclusively for data exchanged between systems, so a file in a legacy single-byte encoding will parse but produce mangled non-ASCII text.
| Format | Adds | Where you meet it |
|---|---|---|
| JSONC | Comments | Editor and compiler config files |
| JSON5 | Comments, trailing commas, unquoted keys, single quotes | Human-edited configuration |
| JSON Lines | One JSON value per line, no enclosing array | Logs and streaming pipelines |
This is why a configuration file ending in .json that is full of comments is not valid JSON and will be rejected by a strict validator, even though the tool that owns it reads it happily. If a formatter refuses your config, check whether the file is actually JSONC before assuming the file is broken.
A formatter checks syntax, not meaning. Valid JSON can still be wrong for its purpose: a missing required field, a string where a number was expected, an enumerated value outside the allowed set. Catching those requires a schema — JSON Schema is the usual tool — and no beautifier can substitute for it.
Formatting also does not change your data, and that includes key order. Order carries no meaning in a JSON object as far as the specification goes, but version-control diffs and checksums care very much, so a reformat that reorders keys will produce a large and misleading diff.
Practical constraints: very large documents will freeze a browser tab, because the whole structure must be held in memory at once alongside the formatted output; deeply nested structures can exhaust the parser stack; and streaming formats such as JSON Lines must be split by line before each record is parsed.
One security habit worth keeping regardless of any privacy claim: avoid pasting production credentials, tokens or personal data into any web tool as a matter of routine. This page processes text in your browser and sends nothing, and you can confirm that yourself by watching the network panel in developer tools — but the general practice of not circulating live secrets through utilities is the stronger protection.
Comments or trailing commas, almost always. Your editor is reading it as JSONC; a validator is reading it as JSON.
Floating-point rounding above 2 to the 53rd. Ask for the identifier as a string, or parse it with a big-integer aware reviver.
No. Only whitespace changes. If a value looks different afterwards, the parser altered it — which points to the number precision issue above.
No. Parsing, validation and formatting all happen in your browser, and nothing you paste is transmitted, logged or stored.
" }, "lorem-ipsum": { "title": "Lorem Ipsum Generator — Its Real Source in Cicero, and When Not to Use It", "description": "Generate placeholder text by words, sentences or paragraphs, plus the actual origin of Lorem Ipsum in Cicero, why the 1500s story is unverified, and the design problems greeking hides.", "keywords": "lorem ipsum generator, lorem ipsum meaning, cicero de finibus placeholder, greeking text, pseudolocalization, content first design", "article": "The most-repeated fact about Lorem Ipsum — that it is meaningless nonsense — is wrong. It is mangled Latin taken from a real book: Cicero's De finibus bonorum et malorum, on the ends of good and evil, written in 45 BC. The relevant passage in Book 1 runs roughly neque porro quisquam est qui dolorem ipsum quia dolor sit amet consectetur adipisci velit, which means, approximately, that nobody loves pain simply because it is pain.
The filler begins mid-word. The original has dolorem ipsum; the placeholder lost the first three letters and starts at lorem ipsum. So the phrase everybody knows is the tail of a Latin word for pain, cut off at an arbitrary point.
The identification is credited to a Latin scholar, Richard McClintock, who noticed that the filler contained consectetur — a word rare enough to trace — and followed it back to Cicero.
Nearly every generator repeats a line about an unknown printer scrambling the text in the 1500s to make a type specimen book. There is no documented evidence for that story. It circulates because one widely copied page said it and thousands of others copied the page.
What is traceable is the modern route. The text was distributed at scale on dry-transfer lettering sheets in the 1960s and 1970s, which is how it reached a generation of graphic designers, and then it was bundled into early desktop publishing software in the 1980s — which is how it reached everyone else. The Cicero source is documented; the Renaissance printer is folklore. Given that the sentence appears in the previous version of this very page, it seemed worth correcting rather than repeating.
The point of placeholder text is to let you judge a text block as a shape — its greyness, line length, leading, rag — without reading it. Recognisable language defeats that, because you start editing the copy instead of assessing the layout.
Latin is well suited to the job for a specific reason: it looks like European prose without being readable to most people. But it is not a neutral substitute for English, and the differences matter:
| Property | Lorem Ipsum | Running English |
|---|---|---|
| Average word length | Noticeably longer | Shorter, dominated by function words |
| Very short words | Few | Very many — the, a, of, to, and |
| Apostrophes | None | Frequent |
| Numerals | None | Common |
| Letters k, w, y, z | Rare or absent | Ordinary |
| Resulting text block | Slightly darker and more even | Lighter, more ragged |
The practical consequence is that a paragraph set in Lorem Ipsum flows more evenly than the same paragraph of English will. Line breaks fall differently, hyphenation is triggered at different points, and a rag that looked clean in the mockup can develop awkward gaps once real sentences arrive.
Placeholder text is most useful when its length matches what will actually be there. Rough targets:
| Slot | Realistic length |
|---|---|
| Page title or hero heading | 4 to 9 words |
| Subheading | 8 to 15 words |
| Card or teaser summary | 15 to 25 words |
| Meta description | about 155 characters |
| Product description | 80 to 150 words |
| Article paragraph | 40 to 80 words |
Generating three fat paragraphs for a slot that will hold twenty words is the commonest way a design passes review and then breaks.
This is the part worth taking seriously, because greeking hides exactly the problems that surface late and cost most.
It hides content that does not fit. If the real headline is eleven words and the mockup used four, the design was never tested. Filler is uniformly well behaved — no long proper nouns, no all-caps acronyms, no unbroken URLs, no product names with a trademark symbol.
It hides the hard languages entirely. German compounds are far longer than their English equivalents and overflow fixed-width buttons; Arabic and Hebrew run right to left and need the whole layout mirrored; Chinese, Japanese and Thai have no spaces, so line breaking follows different rules altogether; and diacritics can collide with tight line height. Latin filler tests none of this. The professional alternative is pseudolocalization — expanding the real strings by 30 to 40% and adding accents and brackets — which surfaces truncation and hard-coded text before translation begins.
It postpones the questions the design exists to answer. Designing with real or realistic content tends to change the design, because the moment you write the actual headline you discover it needs two lines, or that the three benefits are really five. That is an argument for content-first work rather than against placeholder text altogether — filler is a typographic instrument, not a substitute for knowing what the page says.
It ships. Lorem Ipsum reaching production is common enough to be a running joke, and search engines index it happily. Screen readers will attempt to pronounce it. If you use it, leave a marker the build can find, and check for the string before deploying.
The text is not translatable, because it is scrambled — words have been reordered, truncated and in places altered, so it is Latin-shaped rather than Latin. It carries no meaning in the assembled form and should not be presented as a quotation.
It is also only a proxy for one kind of judgement. It will tell you whether a measure is comfortable, whether leading is adequate and whether a grid holds together. It will not tell you whether the hierarchy makes sense, whether the reader can find the action, or whether the page says anything, and no amount of it will.
Only if it is published. A page indexed with filler text has no useful content, which is exactly the signal you do not want. On staging or in a mockup it is irrelevant to search entirely.
Repetition produces a visible vertical pattern in the text block, which distorts the very impression of texture you were trying to assess. Varied word lengths are the point.
Where you can, yes — or at least content of realistic length and shape, including the awkward cases. Keep filler for early typographic exploration and for slots whose content genuinely does not exist yet.
No. The text is assembled in your browser and nothing is transmitted or saved.
" }, "pomodoro-timer": { "title": "Pomodoro Timer — The Rules Most Apps Leave Out, and What the 25 Minutes Really Is", "description": "A Pomodoro timer with the full method: the indivisibility and void rules, estimating work in pomodoros, the daily arithmetic, and an honest account of what the evidence does and does not support.", "keywords": "pomodoro timer, pomodoro technique rules, why 25 minutes pomodoro, estimating in pomodoros, void pomodoro interruption, break schedule focus", "article": "Francesco Cirillo devised the method as a university student in the late 1980s, using a tomato-shaped kitchen timer — pomodoro is Italian for tomato. The interval was the one his timer offered, and he has described starting with a much shorter period and settling on 25 minutes because it worked for him.
That is worth saying plainly, because the number is usually presented as though it were a research finding about attention span. It is not. It is a practical default that turned out to be a reasonable one, and the technique does not depend on it being optimal.
Most timer apps implement the clock and drop the method, which is why people try it, find it unremarkable and stop. The mechanism is not the countdown; it is the discipline around it.
A pomodoro is indivisible. There is no half pomodoro. Either you completed twenty-five minutes on one task, or you did not.
An interrupted pomodoro is void. If you break off and cannot resume immediately, it does not count and you start a fresh one. This sounds harsh and it is the entire point — it puts a real price on picking up your phone, which is the only reason the rule changes behaviour.
Interruptions get written down, not acted on. When something occurs to you mid-interval — an email to send, a thing to look up — you note it on a sheet and continue. For interruptions from other people, Cirillo prescribes a sequence: acknowledge, negotiate a time, call back, and honour it. The note-and-defer habit is what makes the interval defensible.
When the timer rings you stop. Even mid-sentence, even when it is going well. This is the most-broken rule and the one that protects the following four hours.
You record every completed pomodoro. The tally is the feedback loop. Without it the technique is just a timer.
The part almost everyone skips is where the improvement comes from. Before starting, estimate each task in whole pomodoros. Afterwards, record how many it took.
| Task | Estimated | Actual | Error |
|---|---|---|---|
| Draft the proposal | 3 | 5 | +67% |
| Fix the reporting bug | 2 | 4 | +100% |
| Clear the review queue | 4 | 3 | −25% |
The first weeks look like this for nearly everybody, and the systematic direction of the error is the finding. Underestimation of your own tasks is robust and well documented, and no amount of resolving to be realistic fixes it. Comparing estimates against a tally does, slowly, because a pomodoro is a fixed unit and the record is unambiguous. After a month or two most people can size familiar work within one unit.
Anything that exceeds five to seven pomodoros should be split; anything under one should be batched with other small items. That sizing rule is a planning discipline that survives even if you abandon the timer.
| Unit | Composition | Elapsed |
|---|---|---|
| One pomodoro | 25 work + 5 break | 30 min |
| One set | 4 pomodoros, last break extended to 20 | 135 min |
| Realistic day | 8 to 12 pomodoros | 3 h 20 to 5 h of timed work |
| Working week | 50 pomodoros | 20.8 h |
Two things fall out of that table. First, a full day does not contain sixteen pomodoros once meetings, email and lunch are counted — planning for more than about twelve is planning to fail. Second, twenty focused hours a week is a great deal more deliberate work than most weeks contain, so the low number is not a disappointment.
Being straight about this: there is no strong body of controlled research establishing that 25 and 5 is the optimal ratio, or that the Pomodoro Technique outperforms other structured break schedules. Claims to that effect are marketing.
What is better supported sits underneath the method rather than in its specific numbers. Performance on sustained attention tasks degrades over time, and breaks reduce that decline. Deciding in advance exactly when and on what you will work — an implementation intention — reliably improves follow-through compared with a general intention. Recovering from an interruption costs far more than the interruption itself. Each of those supports some timed-interval discipline. None of them singles out this one.
The most substantial criticism is internal. The stop-at-the-bell rule directly conflicts with sustained absorption: if you are twenty-three minutes into something difficult and finally holding the whole problem in your head, a bell is an interruption you have scheduled for yourself. Practitioners who work on long analytical or creative problems commonly abandon the fixed length for that reason, and keep only the record-keeping.
If you do change the length, keep it constant. The moment a pomodoro means 25 minutes on Monday and 50 on Tuesday, the tally stops being a unit of measurement and the estimation loop — the part that produces the gains — breaks.
The technique assumes work that decomposes into uniform blocks under your own control. It fits badly with roles where it cannot: on-call and support work where the interruption is the job, collaborative sessions, days built from meetings, and tasks with a long warm-up before anything useful happens.
It also assumes the timer helps. For some people a countdown adds pressure rather than structure, and watching it becomes its own distraction. Others find external time structure genuinely transformative — the experience varies enough that the only test is a week of trying it.
On that point, one careful note: people with attention difficulties report both extremes, some finding a fixed external interval the single most useful support they have, others finding the forced stop destroys focus that was hard to establish. There is no general answer here and this page is not medical advice; if attention is a persistent difficulty rather than an ordinary bad week, that is worth discussing with a clinician rather than solving with a timer.
Finally, no timer addresses the common underlying problem. Task avoidance is frequently about the feeling attached to a task rather than about time management, and a twenty-five minute block does not make an unpleasant task pleasant. What it does is lower the cost of starting to twenty-five minutes, which is often enough.
The orthodox answer is to stop, because the rule exists to keep you working sustainably rather than in bursts followed by collapse. The pragmatic answer is that finishing the thought and taking the break immediately after costs little. Doing it every time means you have chosen a different method, which is fine — just choose it deliberately.
No. A pomodoro is time you controlled and spent on one chosen task. Counting meetings inflates the tally and destroys its value for estimation.
By the rules it is void. In practice, note it as void and move on without ceremony — the purpose of the rule is to make interruptions visible, not to punish you.
No. The timer runs entirely in your browser, and nothing about your sessions is transmitted or saved. Closing the tab clears it.
" }, "text-reverser": { "title": "Text Reverser — Characters, Words or Lines, and Why Reversing Breaks Unicode", "description": "Reverse characters, word order or line order, and see the four levels at which naive string reversal fails — surrogate pairs, combining accents, flag sequences and joined emoji.", "keywords": "reverse text online, reverse string unicode, grapheme cluster reversal, surrogate pair broken emoji, combining accent reversed, reverse word order", "article": "Reverse means at least three things, and picking the wrong one is the commonest reason the output looks nothing like what was wanted:
| Operation | Input | Output |
|---|---|---|
| Reverse characters | hello world | dlrow olleh |
| Reverse word order | hello world | world hello |
| Reverse each word in place | hello world | olleh dlrow |
Line reversal is a fourth, and it is the one with the most practical use — flipping a log file so the newest entry sits at the top.
For plain English, reversing a string is a first-week programming exercise. For real text it fails at four distinct levels, and each level produces a different flavour of wrong.
Level one — storage units. Most languages store text as UTF-16, in which characters outside the basic multilingual plane occupy two units called a surrogate pair. Reversing unit by unit splits every pair and puts the halves in the wrong order. Each half is meaningless alone, so a thumbs-up emoji does not come back reversed — it comes back as two replacement boxes. The data is destroyed, not rearranged.
Level two — combining marks. An accented letter can be stored as one character or as a base letter followed by a separate combining mark. Reverse the second form and the mark detaches from its letter and lands on the neighbour. The word café, written with a combining acute, reverses so that the accent appears over the f. Nothing errors; the text is simply wrong in a way that is easy to miss in a long string.
Level three — sequences whose order is the meaning. Flag emoji are built from two regional indicator letters standing for a country code. Reversing them does not break the flag — it silently produces a different valid flag:
| Letters | Flag | Reversed | Becomes |
|---|---|---|---|
| S E | Sweden | E S | Spain |
| U A | Ukraine | A U | Australia |
This is the most instructive failure on the page, because there is no error, no replacement character and no visual clue. The output is well-formed and means something else.
Level four — joined sequences. A family emoji is several person characters bound together by invisible zero-width joiners. Reversing the sequence rearranges which characters the joiners sit between, so the group either falls apart into separate figures or recomposes as a different family. Skin-tone modifiers behave the same way: the modifier must follow its base character, and reversal puts it in front of the wrong one.
Several writing systems compound the problem. In Devanagari and Thai, certain vowel signs are stored after the consonant they are pronounced before, so reversal produces sequences that cannot be rendered at all.
| Reverse by | Plain English | Emoji | Accents | Flags |
|---|---|---|---|---|
| Storage unit | Correct | Destroyed | Misplaced | Wrong flag |
| Code point | Correct | Scrambled | Misplaced | Wrong flag |
| Grapheme cluster | Correct | Correct | Correct | Correct |
The right unit is the grapheme cluster — what a reader would call one character. Modern browsers expose this directly through the internationalisation segmenter, which splits text into clusters that can then be reversed as a list. That single change fixes all four failure levels at once, and it is why a correct reverser and a naive one give different output on the same input.
Reversing Arabic or Hebrew is not the mirror-image operation it is for English. Those scripts are stored in logical order — first letter read, first in memory — and the right-to-left display is applied at render time. So reversing the stored characters does not flip the display; it changes the text into a different, usually nonsensical, sequence. Mixed text is stranger still, because a bidirectional algorithm already reorders runs for display, and reversal interacts with it unpredictably.
That gap between stored order and displayed order has a security dimension worth knowing about defensively. Unicode includes explicit direction-override characters, and inserting one into a filename or a link can make the visible text read differently from the actual data — a file that displays as an image can be an executable. Several code-review and messaging tools now flag these characters for exactly this reason. The lesson for anyone handling untrusted strings is that what is displayed is not evidence of what is stored.
Worth stating flatly, because it is often suggested: reversing a password or a secret provides no protection at all. It adds zero entropy, since the transformation is public and has no key, and reversal is one of the standard rules that password-cracking software applies to every candidate in its wordlist by default. A reversed dictionary word is a dictionary word. If the aim is a strong password, the requirement is randomness, not rearrangement.
The same applies to reversed text as a way of hiding content from moderation or search — it is trivially undone, and the systems in question already handle it.
Character reversal is mechanical and knows nothing about language. It will not produce readable mirrored text, and it is not the same thing as upside-down text — that effect is made by substituting entirely different Unicode characters that happen to resemble inverted letters, which is a lookup table rather than a reversal.
Both reversed and substituted text carry a real accessibility cost. A screen reader announces the characters it is given, so reversed text is read as gibberish and substituted upside-down text is read as whatever those unrelated characters actually are. Neither is searchable, neither can be selected meaningfully, and neither should be used for anything a reader needs to understand — including social media names and bios, where it is most common.
The reverser worked on storage units and split a surrogate pair. Nothing can recover it from the output; reverse the original again with grapheme-cluster handling.
Because it was stored as a separate combining mark rather than as part of a precomposed character. Normalising the text to its composed form before reversing avoids this.
No — see above. Cracking tools apply reversal automatically, so it buys nothing.
No. Reversal happens in your browser and nothing you paste is transmitted or saved.
" }, "url-encoder": { "title": "URL Encoder and Decoder — Percent-Encoding, %20 versus Plus, and Double Encoding", "description": "Encode and decode URLs correctly, with the unreserved and reserved character sets, multi-byte UTF-8 worked out, when to use whole-URL versus component encoding, and why %2520 appears.", "keywords": "url encoder decoder, percent encoding rfc 3986, %20 vs plus sign, double encoded url %2520, encodeuricomponent difference, punycode idn", "article": "A URL is limited to a small set of ASCII characters. Anything else is represented as a percent sign followed by the two hex digits of its byte value. The rules come from RFC 3986, which divides characters into three groups.
| Group | Characters | Treatment |
|---|---|---|
| Unreserved | A–Z, a–z, 0–9, hyphen, full stop, underscore, tilde | Never need encoding |
| Reserved | colon, slash, question mark, hash, square brackets, at sign, exclamation, dollar, ampersand, apostrophe, parentheses, asterisk, plus, comma, semicolon, equals | Structural — must be encoded when used as data |
| Everything else | Spaces, accented letters, emoji, all other scripts | Always encoded |
The reserved group is where the thinking happens. A slash separating path segments is doing its job; a slash inside a value is data and must become %2F, or the server will read it as a boundary.
Non-ASCII text is converted to UTF-8 first, then every byte is encoded separately. One character can therefore produce two, three or four escapes:
| Character | Code point | UTF-8 bytes | Encoded |
|---|---|---|---|
| Space | U+0020 | 20 | %20 |
| é | U+00E9 | C3 A9 | %C3%A9 |
| Euro sign | U+20AC | E2 82 AC | %E2%82%AC |
| 中 | U+4E2D | E4 B8 AD | %E4%B8%AD |
This is why a URL containing a few words of Chinese or Arabic becomes enormously long, and it is also why encoding in the wrong character set produces mojibake rather than an error — a byte sequence from a legacy encoding is still valid percent-encoding, just meaningless as UTF-8.
Both mean a space, in different contexts, and confusing them is the single most common URL bug.
| Context | Space becomes |
|---|---|
| Path segment | %20 — a plus here is a literal plus |
| Query string, form-encoded | Plus sign, historically; %20 also accepted |
| Fragment | %20 |
The consequence: a literal plus in a query value must be written as %2B. Searching for the string C++ works only if it is sent as C%2B%2B — send the plus signs raw and the server receives C followed by two spaces. The same trap catches phone numbers in international format and any value that legitimately contains a plus.
Two encoding functions exist because there are two jobs, and using the wrong one is the second most common bug.
| Function | Leaves alone | Use for |
|---|---|---|
| Whole-URL encoding | All structural delimiters — slash, question mark, hash, ampersand, equals, colon | A complete URL you want made safe without breaking it |
| Component encoding | Only unreserved characters plus a handful of legacy exceptions | One value going into a path segment or query parameter |
Encode a query value with whole-URL encoding and any ampersand or equals sign inside it survives — which means the value silently splits into extra parameters. Where that value came from user input, this is not merely a bug, it is parameter injection.
Two footnotes. Component encoding, as implemented in browsers, does not encode the exclamation mark, apostrophe, parentheses or asterisk, although RFC 3986 treats them as reserved sub-delimiters; strict compliance requires handling those separately. And the very old escape function, still found in legacy code, emits a non-standard form for non-ASCII characters that is not valid percent-encoding at all. It should never be used.
Percent-encoding is not idempotent. The percent sign is itself a character that needs encoding, so encoding an already-encoded string transforms every %20 into %2520:
| Pass | Result |
|---|---|
| Original | my file.pdf |
| Encoded once | my%20file.pdf |
| Encoded twice | my%2520file.pdf |
| Encoded three times | my%252520file.pdf |
A URL littered with %25 is the signature: something encoded a value that a framework had already encoded. The fix is to find which layer is doing it and remove one, not to decode twice at the other end — decoding twice will happily decode data that was meant to stay encoded, which is a security problem in its own right.
The same character is treated differently depending on where it sits. A hash sign starts the fragment, and the fragment is never sent to the server — it exists only in the browser, so a value containing a hash must be encoded or everything after it vanishes from the request. An encoded slash inside a path segment is a notorious deployment problem: %2F is semantically distinct from a slash, but many servers and proxies normalise or reject it, so identifiers that can contain slashes are better placed in the query string or base64url-encoded.
Host names are a different system entirely. Internationalised domains are not percent-encoded — they are converted by Punycode into an ASCII form beginning xn--. So the same accented letter is handled one way in the host and another way three characters later in the path. This also underlies homograph attacks, where characters from another script visually imitate a familiar domain, which is why browsers display the punycode form when a name mixes scripts suspiciously.
Percent-encoding makes a string safe to transport. It does nothing to make it safe to use. It does not prevent cross-site scripting, because the value is decoded before it reaches your template; it does not prevent SQL injection, which needs parameterised queries; and it does not prevent open redirects, since a fully encoded external URL decodes back to an external URL.
For input validation the ordering matters and is frequently got wrong: decode exactly once, canonicalise the result, and then validate. Validating before decoding is how encoded traversal sequences slip past filters, and decoding repeatedly until nothing changes reintroduces the same hole from the other direction.
Two practical constraints. The specification sets no maximum URL length, but around 2,000 characters is the safe working ceiling given older browsers, proxies and server defaults — and since encoding can triple the length of non-ASCII text, a URL that looks short can exceed it. And URLs appear in server logs, referrer headers and browser history, so sensitive values belong in a request body, not in a query string, regardless of how well they are encoded.
Just the parameter, in almost every case. Encode each value as you build the URL; never encode a URL you have already assembled unless you intend the delimiters to survive.
Double encoding. Something encoded a string that was already encoded — remove one of the two passes rather than decoding twice.
It was read as a space in the query string. Send it as %2B.
No. Encoding and decoding run in your browser, and nothing you paste is transmitted, logged or saved.
" }, "uuid-generator": { "title": "UUID Generator — 122 Random Bits, Version 7, and the Primary-Key Problem", "description": "Generate version 4 UUIDs, with the bit layout explained, honest collision figures, why bad entropy causes real duplicates, and why random UUIDs make poor clustered primary keys.", "keywords": "uuid generator, uuid v4 collision probability, uuid v7 time ordered, uuid primary key performance, rfc 9562, guid byte order", "article": "A UUID is 128 bits, written as 32 hexadecimal digits in five hyphen-separated groups of 8-4-4-4-12. But not all 128 bits are free. Two fields are fixed by the specification:
| Field | Position | Value in version 4 |
|---|---|---|
| Version | First digit of the third group | Always 4 |
| Variant | First digit of the fourth group | Always 8, 9, a or b |
Four bits of version plus two bits of variant leaves 122 random bits, not 128. That is why every version 4 UUID you generate has a 4 in the same place — a useful sanity check when debugging, and a reminder that a UUID is a structured value rather than a random blob.
Collision risk follows the birthday problem, approximately n² ÷ (2 × 2^122):
| UUIDs generated | Probability of any collision |
|---|---|
| 1 billion | about 1 in 10^19 |
| 1 trillion | about 1 in 10^13 |
| 1 quadrillion | about 1 in 10 million |
| 2.3 × 10^18 | about 50% |
Put in the usual way: generating a billion UUIDs every second for around 85 years gets you to roughly even odds of a single duplicate. For any real application the random-chance risk is not worth modelling.
But that arithmetic has a precondition, and it is where real collisions come from. It assumes 122 bits of genuinely unpredictable randomness. When duplicate UUIDs do turn up in production — and they do — the cause is almost never the birthday bound. It is entropy:
Browsers now expose a correct implementation directly, and using it removes the question. If you are generating UUIDs anywhere else, the thing worth checking is the random source, not the collision maths.
| Version | Built from | Property |
|---|---|---|
| 1 | Timestamp plus network card address | Time-ordered but leaks the machine and creation time |
| 3 and 5 | Hash of a namespace plus a name | Deterministic — same input always gives the same UUID |
| 4 | Random | Unguessable, unordered |
| 7 | Millisecond timestamp plus random | Unguessable in its tail and sortable by creation time |
Version 1 carries a genuine privacy cost that is easy to overlook: the identifier embeds the hardware address of the machine that made it, along with the moment it was made. This is not theoretical — it was famously used in 1999 to trace the author of the Melissa virus through identifiers embedded in the documents. Version 1 UUIDs in a public API leak infrastructure details.
Versions 3 and 5 are underused. Because they are deterministic, hashing a namespace and a stable name produces the same UUID every time, which gives you idempotent identifiers without a lookup table — useful for de-duplicating imports where the source has a natural key but no identifier.
Versions 6, 7 and 8 were standardised in RFC 9562, which replaced the older RFC 4122. Version 7 is the one most projects now want, for the reason in the next section.
The old advice — that UUIDs are unique so you can safely use them as primary keys — is true about uniqueness and misleading about consequences.
A database index is a tree kept in sorted order. Sequential integers append to the end of it, touching one page repeatedly, which stays in memory. Random UUIDs insert at random positions, so every insert touches a different page:
| Effect | Sequential key | Random UUID key |
|---|---|---|
| Pages touched per insert | Usually one, hot in cache | A different one each time |
| Page splits | Rare | Frequent |
| Index fragmentation | Low | High |
| Working set to stay fast | Small | Approaches the whole index |
On low insert volumes this does not matter. On high-volume tables it produces exactly the kind of slowdown that appears months after launch and is hard to attribute.
Storage compounds it. A UUID is 16 bytes as binary. Stored as a 36-character text column — an extremely common mistake — it becomes 36 or 37 bytes, and that inflation is repeated in every secondary index and every foreign key referencing it:
| Representation | Bytes |
|---|---|
| 32-bit integer | 4 |
| 64-bit integer | 8 |
| UUID as binary | 16 |
| UUID as fixed-length text | 36 |
The fixes, in order of preference: use version 7 so identifiers are time-ordered and insert near the end of the index; store as the native UUID type or as 16 raw bytes rather than text; or keep a monotonic internal key for clustering and expose the UUID as a separate indexed column. Version 7 solves most of this with a one-line change and keeps the useful property that identifiers can be generated by the client without a round trip.
Version 4 UUIDs are unguessable, which tempts people into using them as bearer tokens — the unlisted link, the password-reset URL, the invitation. That works up to a point, and the point is worth knowing.
An identifier in a URL appears in server logs, in referrer headers sent to third parties, in browser history, in shared screenshots and in link previews generated by chat applications. It does not expire on its own, it cannot be scoped, and revoking it means invalidating the resource. For anything short-lived and low-value that is an acceptable trade; for account recovery it is not, and such tokens should be separately generated, hashed at rest, scoped and given a short expiry.
Version 1 and version 7 UUIDs are additionally partly predictable, since the timestamp portion is known, so neither should ever be used as a capability token.
UUIDs are canonically lowercase but comparison is case-insensitive, so a system that compares them as raw strings will fail against a source that emits uppercase. Microsoft-style GUIDs are often uppercase and sometimes wrapped in braces, both of which must be normalised away.
There is also a byte-order trap. The Microsoft binary representation stores the first three fields in little-endian order, while the specification defines them big-endian. The same GUID therefore has two different byte layouts, and moving binary values between a .NET system and a standards-compliant one without conversion produces identifiers that look scrambled — a real and frequently painful interop bug.
Finally, they are not human-friendly. Thirty-six characters cannot be read over a phone, quoted in a support ticket reliably, or typed without error. Where a person has to handle the identifier, a short human-readable code alongside the UUID is worth the extra column.
From chance alone, effectively never. From a broken random source, quite easily — which is the risk actually worth guarding against.
Version 7 for database identifiers, because of the index behaviour above. Version 4 where ordering would leak information you would rather not disclose, such as signup sequence or volume.
Only for low-value, short-lived things. It is unguessable but it is not confidential, because URLs travel further than people expect.
No. They are produced by your browser cryptographic random source and nothing is transmitted, logged or stored. Copy what you need before closing the page.
" }, "case-converter": { "title": "Case Converter — Title Case Rules, Programmer Cases, and the Turkish i Problem", "description": "Convert text between upper, lower, sentence, title, camel, snake and kebab case, with the style-guide disagreements, the lossy conversions, and the locale bugs that break naive case changes.", "keywords": "case converter, title case rules chicago ap, camel case to snake case, turkish dotless i bug, german eszett uppercase, unicode case folding", "article": "| Case | Example | Difficulty |
|---|---|---|
| UPPERCASE | THE ANNUAL REPORT IS LATE | Mostly mechanical |
| lowercase | the annual report is late | Mechanical, but destroys information |
| Sentence case | The annual report is late | Needs sentence detection |
| Title Case | The Annual Report Is Late | Needs a style guide and a word list |
Upper and lower look trivial and are, until non-English text arrives — see the locale section below. The other two involve judgement, and any tool that claims to do them perfectly is overselling.
Lowercasing is lossy in a way that cannot be undone. Once Paris becomes paris, nothing in the text records that it was a proper noun. Sentence case applied to a document typed with caps lock on will fix the shouting and simultaneously flatten every name, brand and initialism in it. That is the single most common disappointment with this kind of conversion, and it is worth knowing before you convert several thousand words rather than after.
There is no single correct title case. Every guide capitalises the first and last word and all major words, and they differ on the small ones:
| Guide | Rule for prepositions | Result |
|---|---|---|
| Chicago | Lowercase regardless of length | Look into the Future |
| Associated Press | Capitalise if four letters or more | Look Into the Future |
| APA | Capitalise if four letters or more | Look Into the Future |
So a converter has to pick a side. Beyond that, the cases where automatic title casing reliably fails:
Sentence case has its own trap: sentence boundaries are not full stops. Abbreviations such as Dr. and e.g., decimal numbers such as 3.5, and version strings such as 2.1.4 all produce false boundaries, so a naive splitter capitalises mid-sentence.
| Name | Form | Typical use |
|---|---|---|
| camelCase | parseUserInput | Variables in Java, JavaScript |
| PascalCase | ParseUserInput | Types and classes |
| snake_case | parse_user_input | Python, SQL columns |
| SCREAMING_SNAKE | PARSE_USER_INPUT | Constants, environment variables |
| kebab-case | parse-user-input | URLs, CSS, command flags |
Converting between them looks like a one-line job and is not, because splitting camel case requires deciding where a run of capitals ends. Take parseHTTPResponse. Splitting on every capital gives parse_h_t_t_p_response, which is wrong. Treating a run of capitals as one word gives parse_httpresponse, which is also wrong. The usual rule — a run of capitals is one word, except that its last letter belongs to the following word if a lowercase letter follows — gives parse_http_response, which is right here.
But that rule cannot always be right, because the information is genuinely absent. HTTPSConnection could be HTTPS plus Connection or HTTP plus SConnection, and no algorithm can tell without a dictionary. Round-tripping identifiers through case conversions is therefore not guaranteed to return the original, which matters if you are generating code or migrating a schema.
Case is not a per-character property in every language, and this produces real bugs.
Turkish and Azerbaijani. These languages have two distinct letter i: dotless ı and dotted i, with separate capitals I and İ. In a Turkish locale, uppercasing i correctly yields İ, and lowercasing I correctly yields ı. A locale-aware case conversion applied to English text inside a Turkish locale therefore turns file into FİLE, and a lowercase comparison of FILE returns fıle, which matches nothing. This has broken configuration parsing, command handling and authentication checks in shipped software many times. The lesson is narrow and useful: never use a locale-sensitive case conversion for comparing machine-readable strings such as keys, tags, protocol tokens or file extensions.
German. The letter ß has historically uppercased to SS, so straße becomes STRASSE and lowercasing that gives strasse — a round trip that silently changes the word. A capital form ẞ exists and was admitted as an official alternative in 2017, but most software still expands to SS.
Greek. Lowercase sigma has two forms: ς at the end of a word and σ elsewhere. Lowercasing Greek capitals correctly requires knowing where words end, so it is context-sensitive rather than character-by-character.
A related point: some characters change length when case is changed. One ß becomes two letters. Any code that assumes an uppercased string has the same length as its input, or that character positions line up before and after, is wrong for these inputs.
If your goal is to compare two strings ignoring case, lowercasing both is the intuitive approach and the wrong one. Unicode defines case folding for exactly this purpose: it is locale-independent, it folds ß to ss so the German pair compares equal, and it normalises the two sigmas.
This matters most for usernames and identifiers, where case-insensitive matching decides whether two accounts are the same account. Some characters fold together that do not look alike — the Kelvin sign folds to a plain k, and several mathematical and compatibility letters fold to ordinary Latin ones. Normalising registration input with folding plus Unicode normalisation, and rejecting mixed scripts, is the standard defence against lookalike account collisions.
If you only want text to look uppercase on a web page, a stylesheet text transform is the better tool: the underlying content is unchanged, so copying the text yields the original wording, translators see real sentences, and you can change your mind without re-editing content. Converting the characters themselves is for when the stored value must change.
Two accessibility notes on all capitals. Screen readers may read a run of capitals letter by letter when it looks like an initialism, so a whole heading in capitals can be announced as individual letters. And research on continuous reading, going back to Miles Tinker legibility studies, has consistently found all-capital text slower to read than mixed case — roughly ten percent — because the distinct outline shape of words is lost. Capitals are fine for short labels and poor for sentences.
For search: capitalisation is not a ranking factor, and search engines fold case when matching queries. Titles are shown as written, so a heading in shouting capitals affects click-through rather than position.
Whichever your publication uses. If you have no house style, pick one and stay consistent — inconsistency across headings is more visible to a reader than either convention.
Almost certainly a locale-sensitive conversion applied to data. Use a locale-independent conversion for machine-readable strings and a locale-aware one only for text a person will read in that language.
Not reliably. The capitals carried the information and it is gone. Keep the original until you have checked the result.
No. The conversion runs entirely in your browser. Nothing is uploaded, logged or stored, which is the reason this is safe to use on unpublished or confidential copy.
" }, "roman-numerals": { "title": "Roman Numeral Converter — The Rules, the Valid Forms, and What the System Cannot Do", "description": "Convert numbers to Roman numerals and back, with the thirteen-pair algorithm, worked conversions, which forms are invalid, and why clock faces still show IIII.", "keywords": "roman numeral converter, roman numeral rules, why clocks use IIII, roman numerals above 3999, invalid roman numerals IL IC, MMXXVI", "article": "| Symbol | Value |
|---|---|
| I | 1 |
| V | 5 |
| X | 10 |
| L | 50 |
| C | 100 |
| D | 500 |
| M | 1000 |
The additive rule: symbols in descending order are added, so LXVII is 50 plus 10 plus 5 plus 1 plus 1, or 67. The subtractive rule: a smaller symbol placed before a larger one is subtracted, so IX is 9 and CD is 400.
The subtractive rule is tightly constrained, and this is where most hand-written numerals go wrong. Only I, X and C may be subtracted, and each only from the next two values up:
| May precede | Valid | Invalid |
|---|---|---|
| I before V and X | IV, IX | IL, IC, ID, IM |
| X before L and C | XL, XC | XD, XM |
| C before D and M | CD, CM | — |
| V, L, D | never subtracted | VX, LC, DM |
Two further constraints: I, X, C and M may repeat at most three times, and V, L and D never repeat at all. So 1999 is MCMXCIX, not MIM — a form that appears constantly and is not valid, because I cannot be subtracted from M.
Every standard converter uses the same table of thirteen value-and-symbol pairs, taken largest first, subtracting as many times as each fits:
| Value | Symbol | Value | Symbol |
|---|---|---|---|
| 1000 | M | 40 | XL |
| 900 | CM | 10 | X |
| 500 | D | 9 | IX |
| 400 | CD | 5 | V |
| 100 | C | 4 | IV |
| 90 | XC | 1 | I |
| 50 | L |
Including the four subtractive pairs in the table is what makes the greedy approach produce valid output automatically — there is no separate step that decides when to subtract.
Worked example, 2026. Take 1000 twice, leaving 26. Take 10 twice, leaving 6. Take 5, leaving 1. Take 1. Result MMXXVI, and checking backwards: 1000 plus 1000 plus 10 plus 10 plus 5 plus 1 is 2026.
Worked example, 1994. Take 1000, leaving 994. Nine hundred fits, so CM, leaving 94. Ninety fits, so XC, leaving 4. Four fits, so IV. Result MCMXCIV, which reads as 1000 plus 900 plus 90 plus 4.
Reading in the other direction is a single pass: add each symbol value, but subtract instead of adding whenever the current symbol is smaller than the one after it.
Strict subtractive notation is a later standardisation, not classical practice. Roman inscriptions and manuscripts use IIII and XXXX freely alongside IV and XL, and the choice was often a matter of the space available or the mason preference. The tidy rule set above was settled long after Rome.
Clock dials preserve the older habit, and IIII rather than IV is still the overwhelming convention on traditional dials. Several explanations circulate — visual balance against the VIII opposite it, avoiding a resemblance to the initials of the Roman god Jupiter, easier casting of moulds when the numerals are struck rather than engraved — and none of them is documented well enough to state as fact. What is safe to say is that IIII on a clock is not an error, and that a converter which only ever emits IV is following a modern convention rather than a historical one.
There is no zero. The seven symbols have no way to write nothing, which is not a gap in the notation so much as a difference in what it is for: it is a tally-derived system for recording quantities, not a positional system for calculating with them. Medieval computists working out Easter dates simply wrote the word for nothing, and the letter N stood in for zero in Bede calendrical tables in the eighth century.
There is no place value. Written arithmetic in Roman numerals is awkward, which is why Romans did not do it that way — calculation happened on a counting board or abacus and only the result was written down. The frequent claim that Roman numerals held back mathematics for centuries overstates it; the counting board handled the arithmetic perfectly well.
There are no fractions in the seven symbols. Romans used a separate duodecimal scheme for parts, with S for a half and dots for twelfths — unrelated to the letters and not supported by any modern converter.
There is a ceiling at 3999. With three M at most, the largest expressible number is MMMCMXCIX. Above that, historical practice used a vinculum — an overline multiplying a numeral by a thousand — or the older bracketing notation. Neither is well supported in plain text, so most tools, including this one, stop at 3999 rather than inventing a form.
Roman numerals survive in clock dials, film and broadcast copyright lines, the front matter of printed books, regnal and papal numbers, chemical oxidation states, and chord analysis in music theory. The American football championship used them continuously until the fiftieth game in 2016, which was branded with an Arabic 50 because L on its own looked wrong, and then reverted to LI the following year — a good illustration of the system being a typographic choice rather than a numeric one.
Three things worth knowing if numerals end up in software:
Two pieces of trivia that are actually verifiable: the longest year written in Roman numerals in the modern era was 1888, thirteen characters as MDCCCLXXXVIII, and the longest number below four thousand is 3888 at fifteen characters, MMMDCCCLXXXVIII.
Not historically, and not on a clock. In modern prose and for anything a style guide governs, use IV.
Usually because one of them permits non-standard subtractive forms. MCMXCIX and MIM look like alternatives for 1999 but only the first is valid, and a lenient tool may produce or accept the second.
There is no plain-text standard. An overline multiplying by a thousand is the historical answer, but it needs typography rather than characters, which is why most converters stop.
No. The conversion runs in your browser and nothing is sent to a server, logged or stored.
" }, "percentage-calculator": { "title": "Percentage Calculator — Four Formulas, and the Mistakes That Cost Real Money", "description": "Work out a percentage of a number, percentage change, and reverse percentages, with worked figures and the traps: percentage points, stacked discounts, margin versus markup and asymmetric recovery.", "keywords": "percentage calculator, percentage change formula, percentage points vs percent, stacked discount calculation, margin vs markup, reverse percentage vat", "article": "Nearly every percentage problem is one of these, and the mistakes almost always come from solving the wrong one:
| Question | Formula | Example |
|---|---|---|
| What is P% of N? | N × P ÷ 100 | 20% of 50 is 10 |
| X is what percent of Y? | X ÷ Y × 100 | 37 of 240 is 15.42% |
| Change from A to B? | (B − A) ÷ A × 100 | 180 to 234 is +30% |
| N is P% of what? | N ÷ (P ÷ 100) | 96 is 120% of 80 |
The fourth is the one people get wrong most often, and it has a name: the reverse percentage. If a price of 96 includes 20% tax, the tax is not 20% of 96. Dividing gives the base: 96 ÷ 1.20 = 80, so the tax is 16. Taking 20% of the gross instead gives 19.20 and a base of 76.80, which is wrong by 3.20 on every line of an invoice.
A 50% fall followed by a 50% rise does not get you back. Starting at 100: down 50% is 50, up 50% is 75. The reason is that the second percentage applies to a smaller base. The gain needed to undo a loss is d ÷ (1 − d):
| Fall | Rise needed to recover |
|---|---|
| 10% | 11.1% |
| 20% | 25% |
| 25% | 33.3% |
| 50% | 100% |
| 80% | 400% |
This is why a portfolio down 30% and then up 30% is at 91, and why a metric described as having recovered its percentage drop usually has not.
Twenty percent off, then a further ten percent off, is not thirty percent off. The multipliers combine: 0.80 × 0.90 = 0.72, so the total discount is 28%.
| Two discounts | Sum (wrong) | Actual |
|---|---|---|
| 20% then 10% | 30% | 28% |
| 30% then 20% | 50% | 44% |
| 25% then 25% | 50% | 43.75% |
| 50% then 50% | 100% | 75% |
The same arithmetic settles a question shoppers argue about: whether a discount should be applied before or after tax. Since both are multiplications, the order does not change the total. A 100 item with 10% off and 8% tax comes to 97.20 either way — 90 × 1.08 and 108 × 0.90 are the same number. Order does matter when one of them is a fixed amount rather than a percentage, and some jurisdictions specify which base tax applies to, so a receipt can differ from your arithmetic for legal rather than mathematical reasons.
This one has real consequences for anyone pricing goods. Buy for 60, sell for 100. The profit is 40. Divided by the selling price that is a 40% margin; divided by the cost it is a 66.7% markup. Same transaction, two numbers, and quoting one when you mean the other underprices the product.
| Margin | Equivalent markup |
|---|---|
| 10% | 11.1% |
| 20% | 25% |
| 30% | 42.9% |
| 40% | 66.7% |
| 50% | 100% |
To convert, markup = margin ÷ (1 − margin). Applying a 30% markup when you wanted a 30% margin leaves you with a 23% margin, which on thin-margin goods is most of the profit.
If an interest rate moves from 4% to 6%, that is a rise of two percentage points and also a rise of fifty percent. Both are correct and they describe the same event with numbers that differ by a factor of twenty-five.
This is the single most exploited ambiguity in reporting about rates — conversion rates, tax rates, interest rates, unemployment, poll shares. When a claim about a rate uses the word percent without saying which, the figure is uninterpretable, and the more impressive-sounding version is usually the one chosen. If you are writing the number, say percentage points when that is what you mean.
Ten percent growth per month for a year is not 120% growth. It is 1.10^12 = 3.138, or +213.8%. Conversely, going from 100 to 180 over five years is not 16% a year; the annualised rate is 1.8^(1/5) − 1 = 12.47%, and checking it forwards, 1.1247 to the fifth power returns 1.80.
Averaging percentages is valid only when the bases are equal. Consider two shops: one converts 2 of 10 visitors, the other 30 of 1,000. The average of 20% and 3% is 11.5%. The actual combined rate is 32 ÷ 1,010 = 3.17%. Always recombine the raw counts and divide once; averaging the rates weights a tiny sample equally with a large one.
Percentages of very small samples, of changing populations, or of figures that were themselves estimates carry all the uncertainty of their inputs without showing it. Keeping the raw numbers next to the percentage is the cheapest defence.
Divide by one plus the rate. For 20%, divide the gross by 1.2 to get the net; the difference is the tax. Do not multiply the gross by the rate.
No, 43.75% off. Multiply 0.75 by 0.75 to get the remaining share of 0.5625.
Divide the cost by 0.60, not multiply by 1.40. On a cost of 60 that is 100 rather than 84.
No. Every calculation runs in your browser, and nothing is transmitted, logged or stored — which is why this is safe for pricing and salary figures you would rather not paste into an online form.
" }, "time-zone-converter": { "title": "Time Zone Converter — Why Meetings Drift, and What a Converter Cannot Know", "description": "Convert times between zones, with the overlap arithmetic for real working hours, the three weeks each year when offsets change, and an honest account of the limits of any time zone data.", "keywords": "time zone converter, meeting planner across time zones, dst transition dates differ, working hours overlap calculator, iana time zone database, est vs edt", "article": "Offsets run from UTC−12 to UTC+14, a span of 26 hours. One consequence is that for about two hours of every day, three different calendar dates are in use somewhere on Earth at the same instant — which is why a date on its own is not a time, and why an unqualified deadline of Friday can be a day and a half wide.
Not every offset is a whole hour, either:
| Offset | Where |
|---|---|
| UTC+5:30 | India, Sri Lanka |
| UTC+5:45 | Nepal |
| UTC+3:30 | Iran |
| UTC+9:30 | Central Australia |
| UTC+12:45 | Chatham Islands |
| UTC−3:30 | Newfoundland |
Any scheduling logic that assumes offsets are whole hours breaks on roughly a fifth of the world population, most of it in South Asia.
Daylight saving changes are not synchronised. The European Union switches on the last Sunday in March and the last Sunday in October. The United States switches on the second Sunday in March and the first Sunday in November. In the gaps:
A standing call at 14:00 London and 09:00 New York cannot hold both of those times through those weeks. One side moves, and which side moves is whatever the calendar software decided when the invitation was created. This is the single most common cause of somebody joining an hour early, and it is not a bug in anyone tool — it is two governments choosing different Sundays.
Across the equator it is larger. London to Sydney ranges from nine to eleven hours over the year, because the two hemispheres shift in opposite directions and their transition dates do not line up. There is no single correct answer to how far ahead Sydney is.
Within a single country it can vary too. Queensland and Western Australia do not observe daylight saving while New South Wales and Victoria do, so Sydney and Brisbane share a clock for half the year and are an hour apart for the other half. Arizona does not observe it, but the Navajo Nation inside Arizona does, and the Hopi Reservation inside the Navajo Nation does not — so a short drive can cross the same boundary three times.
Knowing the offset is less useful than knowing how much of the day both parties are awake for. Taking a 09:00 to 17:00 day on both sides, from London in summer:
| With | Gap | Shared working hours |
|---|---|---|
| Berlin | 1 hour | 7 hours |
| Delhi | 4.5 hours | 3.5 hours |
| New York | 5 hours | 3 hours |
| San Francisco | 8 hours | none |
| Sydney | 9 to 11 hours | none |
The San Francisco and Sydney rows are the honest answer to a question people keep asking a converter to solve: there is no time that suits both. Something has to give, and the choices are a standing early or late slot, rotating which side absorbs it, or making the work asynchronous. A converter can tell you what 08:00 in one city is in another; it cannot make an overlap exist.
Time zone abbreviations are not unique, and several are actively contradictory:
| Abbreviation | Could mean |
|---|---|
| CST | US Central (UTC−6), China (UTC+8), Cuba (UTC−5) |
| IST | India (UTC+5:30), Ireland (UTC+1), Israel (UTC+2) |
| BST | British Summer (UTC+1), Bangladesh (UTC+6) |
| AMT | Amazon (UTC−4), Armenia (UTC+4) |
There is a second, quieter error: EST means Eastern Standard Time, which New York is not on in July — it is on EDT. Writing 15:00 EST for a July call names a time that does not currently exist there. Most people read it as Eastern and get it right anyway, but automated parsers do not.
The unambiguous forms are the offset (15:00 UTC+01:00), the full ISO timestamp with offset, or the IANA zone identifier such as Europe/London or America/New_York. Zone identifiers are the right choice because they carry the whole history and future ruleset, not one moment of it.
The claim that a tool handles all daylight saving rules and always returns the mathematically correct local time deserves qualifying, because it is only true of the past.
Zone rules come from the IANA time zone database, which publishes several revisions a year, and your browser knows only the version bundled with it. Converting a date in the future is therefore a prediction that the current rules will still apply. Governments change them, often with weeks of notice:
Two further genuine gaps. On the spring transition an hour of local time does not exist — a 02:30 alarm has no instant to fire at — and on the autumn transition an hour happens twice, so a local timestamp of 01:30 is ambiguous without an offset. Scheduled jobs get skipped or run twice on those two nights every year, and log files from those hours cannot be ordered by their local timestamps alone.
Finally, UTC is not quite the same thing as GMT, and leap seconds have historically been inserted to keep clocks aligned with the rotation of the Earth. The most recent was in 2016, and in 2022 the international body responsible voted to abandon the practice by 2035 — largely because of the trouble a repeated second causes in computing.
The rule that saves the most pain: store past events as an absolute instant in UTC; store future appointments as a local time plus a zone identifier.
A meeting set for 09:00 next March in Berlin should stay at 09:00 in Berlin even if Germany changes its rules in the meantime. Store it as an instant and it will silently move to 08:00 or 10:00. A log entry, by contrast, records something that already happened at a fixed instant and belongs in UTC forever. Converting to local time is a display step, done as late as possible.
Almost certainly a transition gap — the two countries changed their clocks on different Sundays. It corrects itself when the second one switches.
Nine, ten or eleven hours from London depending on the month. Any single figure is wrong for part of the year.
A full date, the time, and either the offset or the city — and for anything crossing more than a few zones, the UTC time alongside it. Abbreviations are the thing to avoid.
No. The conversion uses your device clock and time zone locally in the browser. Nothing is sent to a server, logged or stored.
" }, "slug-generator": { "title": "Slug Generator — The Nine-Step Pipeline, and Why Transliteration Has No Right Answer", "description": "Turn titles into URL slugs, with the exact processing order, why accented characters have no single correct transliteration, how slugs collide, and why changing one later is expensive.", "keywords": "slug generator, url slug best practices, transliteration for urls, hyphens vs underscores seo, slug collision handling, changing a url slug redirect", "article": "In example.com/guides/how-to-tie-a-tie, the path is /guides/how-to-tie-a-tie and the slug is the final segment: how-to-tie-a-tie. It is the human-readable handle for one page, and unlike a title it is part of an address — which means it is subject to encoding rules, uniqueness constraints and the awkward fact that other people link to it.
Order matters, and most homemade slug functions get two or three of these wrong:
| Step | Why |
|---|---|
| 1. Normalise Unicode | Separates accents from base letters so they can be handled |
| 2. Transliterate or strip marks | Turns é into e rather than deleting the letter |
| 3. Lowercase, locale-independently | A locale-aware lowercase corrupts Turkish text |
| 4. Replace runs of anything else with a hyphen | Spaces, punctuation, symbols |
| 5. Collapse repeated hyphens | Otherwise punctuation clusters leave gaps |
| 6. Trim hyphens from both ends | A title ending in a question mark leaves a trailing one |
| 7. Truncate at a word boundary | Cutting mid-word reads as a mistake |
| 8. Guard reserved words | A slug of admin or api can shadow a real route |
| 9. Check uniqueness | Different titles can produce identical slugs |
Step three is the one with a real bug attached. If you lowercase using the user locale and that locale is Turkish, the letter i becomes a dotless ı, and every slug generated on that machine differs from the ones generated everywhere else. Slug generation is machine text handling, so it needs the locale-independent conversion.
This is the part that tools quietly get wrong, because the right output depends on the language of the text, not on the characters in it:
| Input | Naive | Language convention |
|---|---|---|
| München | munchen | muenchen (German) |
| Malmö | malmo | malmo (Swedish, not malmoe) |
| straße | strae | strasse |
| Škoda | skoda | skoda |
| naïve | naive | naive |
German convention expands the umlaut to a following e, so ü becomes ue. Swedish does not — ä becomes a. The same code point therefore wants two different outputs depending on which language the title is in, and no generator can infer that from the string. German ß is worse: dropping the mark leaves nothing, so a generator that only strips marks turns straße into strae, which is not a word in any language.
For non-Latin scripts there is no stripping possible at all. Greek has competing transliteration standards that disagree; Chinese requires word segmentation and a dictionary before pinyin can be produced. The two legitimate options are a language-specific mapping table you maintain deliberately, or keeping the native script in the URL.
Native script is more viable than it used to be. Browsers display Unicode paths readably, and search engines index them without difficulty. The trade-off is that the underlying URL is percent-encoded, so a six-letter Cyrillic or Arabic word becomes a long run of percent-escapes the moment somebody pastes the link into plain text or an email client — visually alarming even though it works. For an audience reading that script it is usually worth it; for a mixed international audience, transliteration is calmer.
Use hyphens. The historical reason is that search engines treated a hyphen as a word separator and an underscore as a joiner, so my_first_post was read as one long token. The engines have largely converged and the ranking difference now is small to nonexistent, but the convention stands for two better reasons: hyphens are what everyone expects, and an underscore is frequently invisible in a URL rendered with an underline, so readers cannot tell whether the gap is an underscore or a space.
Never use spaces — they become %20 — and avoid anything from the reserved set, so no plus signs, ampersands, question marks, hashes or slashes inside a slug.
Stripping stop words is often a mistake. The common advice to remove and, the and a comes from an era of keyword-stuffed URLs. There is no ranking bonus for a shorter slug, and removing them can wreck the match with how people actually search: how-to-tie-a-tie mirrors the query, while tie-tie does not, and reads like a truncation error. Remove filler when a slug is genuinely unwieldy; do not remove it as a rule.
Slugs are not a ranking lever. A descriptive URL helps a person decide whether to click, and search engines have said readable URLs are preferable, but no amount of keyword packing in the path moves position. Search results often display a breadcrumb rather than the full path, so words beyond the first few are frequently not shown at all.
Dates in slugs age badly. A path with a year in it makes an updated evergreen article look stale and makes the URL wrong once you revise it.
Stripping punctuation collapses genuinely different titles. A guide to C++ and a guide to C# both slugify to c-guide, because both symbols vanish. So do Node.js Basics and Node JS Basics. Two real fixes: keep a small mapping so that plus signs and sharps become words such as cplusplus and c-sharp, and always check the generated slug against existing ones before saving, appending a numeric suffix when it clashes.
The reserved-word check matters too. A page whose title happens to be Admin, API, Login or Static can produce a slug that collides with an application route, which is either a broken page or, in a badly ordered router, an unintended one.
One more: a slug containing a Cyrillic character that looks identical to a Latin one produces two distinct URLs that are visually indistinguishable. Restricting output to a known character set closes that off.
Once published, a slug is referenced by links, bookmarks, shared messages and search indexes you do not control. Changing it breaks all of them unless the old address keeps working through a permanent redirect — and even then, redirect chains accumulate and some referrers do not follow them.
The structural answer is to decouple identity from wording: a path of /123/my-article-title can resolve on the number alone, so the words can change freely while every old link still lands. If the slug alone is the identifier, plan on issuing a permanent redirect and keeping it indefinitely.
A related detail worth fixing once: on a case-sensitive server, /My-Post and /my-post are two different URLs serving the same content, which is a duplicate-content problem. Redirect anything with uppercase to the lowercase form, pick one convention for the trailing slash, and set a canonical link.
Hyphens. The ranking gap has narrowed but the readability and convention arguments have not.
Only if the slug is too long. Removing them from a short, query-matching slug makes it worse, not better.
Yes, but budget for it: a permanent redirect from the old path, kept in place for good, plus updates to any internal links.
No. Slugs are generated in your browser and nothing is uploaded, logged or stored, so unpublished titles stay unpublished.
" }, "regex-tester": { "title": "Regex Tester — Greedy Matching, Catastrophic Backtracking, and What Regex Cannot Do", "description": "Test regular expressions against sample text, with the concepts that cause most bugs: greedy versus lazy quantifiers, flag behaviour, exponential backtracking, and the validation jobs regex should not be given.", "keywords": "regex tester, greedy vs lazy quantifier, catastrophic backtracking redos, email validation regex, regex cannot parse html, regex flags dotall unicode", "article": "A regular expression is not a search string. It is a small program, and the engine most languages use runs it by walking the text from left to right, trying each alternative in turn and backtracking when a path fails. Almost every regex mystery — why a pattern matches too much, why it is slow, why it hangs — comes from that backtracking. A tester is useful because it shows you the result, but the model is what lets you predict it.
| Piece | Means |
|---|---|
| . | Any character except a newline |
| [abc] and [^abc] | One of these, and one not of these |
| [0-9] or \d | A digit |
| * + ? | Zero or more, one or more, zero or one |
| {2,5} | Between two and five |
| ^ and $ | Start and end of the text |
| \b | A word boundary — position, not a character |
| (...) and (?:...) | Capturing group, non-capturing group |
| a|b | Either alternative |
| (?=...) and (?!...) | Lookahead: assert without consuming |
The word boundary is worth singling out because it is the fix for the commonest false positive. Searching for cat finds it inside concatenate; searching for \bcat\b does not.
Quantifiers take as much as they can and only give characters back when forced. Given the text <b>bold</b> and <b>more</b>:
| Pattern | Matches |
|---|---|
<b>.*</b> | The entire string, from the first tag to the last |
<b>.*?</b> | Each pair separately, as intended |
The greedy version is not broken — it is doing exactly what it was told. Adding the question mark makes the quantifier lazy, so it takes the least it can and expands only as needed. If a pattern is capturing far more than you expected, this is nearly always why.
| Flag | Effect |
|---|---|
| i | Case-insensitive |
| g | Find all matches, not just the first |
| m | ^ and $ match at each line, not just the whole text |
| s | The dot also matches newlines |
| u | Treat the pattern as Unicode code points |
Two defaults surprise people. The dot does not match a newline unless you ask, so a pattern intended to grab a multi-line block silently stops at the first line ending. And ^ means start of the whole text, not start of a line, until you add the multiline flag — the source of countless patterns that work on one-line samples and fail on a real file.
The global flag has a trap of its own in JavaScript: a regex object with g keeps a position between calls, so testing the same pattern object against the same string repeatedly returns true, then false, then true. If a validation function alternates between accepting and rejecting identical input, this is the cause. Create the pattern where you use it, or drop the flag when you only need a yes or no.
Nested quantifiers over overlapping content make the number of paths the engine must try grow exponentially. The textbook example is (a+)+b tested against a run of the letter a with no b at the end. Every way of splitting the run between the inner and outer quantifier is a distinct path, and there are roughly two to the power of the length:
| Letters of input | Approximate paths tried |
|---|---|
| 10 | a thousand |
| 20 | a million |
| 30 | a billion |
| 40 | a trillion |
A twenty-character difference in input turns instant into forever. This is not a curiosity: it is a denial-of-service class in its own right, and it has caused well documented outages. A regular expression in a web application firewall rule took Cloudflare offline globally in July 2019 by consuming CPU across its fleet, and a pattern matching trailing whitespace on user posts took Stack Overflow down in July 2016. In both cases the pattern was correct and had passed review.
The defences, in order of usefulness: avoid a quantifier inside a quantified group; make alternatives mutually exclusive so there is nothing to redistribute; put an upper bound on repetition rather than using an open-ended plus; anchor the pattern so failure is detected early; and where the language offers atomic groups or possessive quantifiers, use them to forbid backtracking outright. Some environments provide an engine that cannot backtrack exponentially at all, which is the structural fix if you run untrusted patterns.
The testing habit that matters: try your pattern against a long input that almost matches but fails at the end. Happy-path samples never reveal this.
Email addresses. Regex is routinely recommended for this and it is a poor fit. The address grammar in the relevant standard permits quoted local parts, comments in parentheses and other structures that no readable pattern captures; the well known attempts at full compliance run to thousands of characters and still get edge cases wrong. Worse, strict patterns cause real harm by rejecting valid addresses — plus-addressing, apostrophes in names, long or newer top-level domains, non-ASCII local parts.
And even a perfect pattern cannot tell you whether the mailbox exists or accepts mail, which is the thing you actually wanted to know. The defensible approach is a loose sanity check such as ^[^@ ]+@[^@ ]+\.[^@ ]+$, or the browser email input type, followed by sending a confirmation message. Deliverability is verified by delivering.
Nested structures. HTML, XML and JSON nest to arbitrary depth, and a regular expression cannot count depth — this is a formal limitation of the class of languages regular expressions describe, not a matter of writing a cleverer pattern. Every regex-based HTML extractor works on the samples it was written against and breaks on attributes containing angle brackets, comments, or unexpected nesting. Use a parser. The same applies to CSV once fields can contain quoted commas and embedded line breaks.
A related note on passwords. Composition patterns that demand an uppercase letter, a digit and a symbol are easy to express as regex and have fallen out of favour for good reason — the 2017 revision of the United States federal digital identity guidance dropped mandatory composition rules, because they push users towards predictable substitutions rather than genuine unpredictability. Checking length and screening against a list of breached passwords does more than any pattern.
A pattern that works in one language may not compile in another. Lookbehind is unsupported or restricted in several engines; named group syntax differs; POSIX bracket classes exist in some flavours and not others; and the digit shorthand means ASCII digits only in some engines and any Unicode digit in others — a difference that matters for validation.
Unicode is its own hazard. Without the Unicode flag, the dot and the quantifiers operate on storage units rather than characters, so a single emoji counts as two and a pattern limiting input to a fixed length behaves unpredictably. Turning the flag on, and using grapheme-aware handling where user-visible characters matter, avoids a family of bugs that only appear once real users arrive.
Use named groups instead of counting positions. Break a long pattern into two or three simpler steps applied in sequence — one comprehensible pattern plus a line of code beats one unreadable pattern. Where the language supports an extended mode, use it to add whitespace and comments. And when a pattern exceeds about eighty characters, treat that as a signal that the job may belong to a parser.
Greedy quantifiers. Add a question mark after the star or plus to make them lazy, and check whether you need a word boundary.
Almost certainly nested quantifiers on overlapping input. Test with a long near-match, then remove the nesting or bound the repetition.
A reused pattern object with the global flag remembering its position. Remove the flag or build the pattern fresh.
No. Matching runs in your browser and nothing is transmitted, logged or stored — which matters, since sample text pasted into a tester is often real production data.
" }, "reading-time": { "title": "Reading Time Estimator — The Model, Its Assumptions, and What the Label Hides", "description": "Estimate how long an article takes to read, with the measured speeds by reading mode, adjustments for images and code, and an honest look at whether the read-time label helps at all.", "keywords": "reading time estimator, average reading speed words per minute, medium read time algorithm, reading time for code blocks, does read time increase engagement", "article": "Reading time is minutes = words ÷ words per minute, rounded up. That is the whole model. Everything interesting is in the divisor, because the divisor is an assumption rather than a measurement of your reader.
The best available figures come from a 2019 meta-analysis pulling together around 190 studies of reading rate, and they differ by mode rather than by person:
| Mode | Words per minute |
|---|---|
| Silent reading, non-fiction | about 238 |
| Silent reading, fiction | about 260 |
| Reading aloud | about 183 |
Individual variation around those means is wide, and studies using different texts and tasks land anywhere from roughly 175 to 300 for ordinary adult silent reading. That range is not a rounding detail — it changes the answer substantially:
| A 1,500-word article | Estimated time |
|---|---|
| At 180 wpm | 8.3 minutes |
| At 238 wpm | 6.3 minutes |
| At 300 wpm | 5.0 minutes |
The same text is a five-minute read or an eight-minute read depending purely on a constant nobody sees. Any tool describing its output as accurate is overstating what the arithmetic can deliver; what it delivers is a consistent, comparable estimate, which is genuinely useful and is not the same claim.
With whole-minute rounding up at 238 words per minute, an article of 240 words and an article of 470 words both display two minutes. The label is a bucket, not a measurement, and the buckets are wide at the short end.
This is also why displaying seconds is a mistake. A label reading 6 minutes 43 seconds claims a precision the underlying model cannot support — the divisor is uncertain by twenty percent or more. Whole minutes, or the word about, is the honest presentation.
Counting words treats a page as uniform prose. Real articles are not, and these are the adjustments that matter:
One implementation bug is worth naming because it is so common: counting the whole rendered page rather than the article body. Navigation, sidebar, footer links, author biography and comments can add hundreds of words, inflating every estimate on the site by a minute or more.
The claim that displaying an estimate increases the chance a reader finishes is repeated everywhere, including in the previous version of this page. It deserves to be stated more carefully: there is no published controlled research establishing that effect. Read-time labels became a convention after Medium adopted them around 2014, and the supporting evidence is internal product data rather than anything independently replicated.
The plausible mechanism also cuts both ways. A label reading three minutes lowers the barrier to starting. A label reading eighteen minutes tells a reader on a phone in a queue to come back later, which may mean never. Setting an expectation reduces uncertainty, and it also gives people a reason to decline.
Two secondary effects are worth watching for. Authors start writing to the number, padding a five-minute piece to look substantial or cutting necessary material to stay under a threshold. And readers use the label as a quality proxy, which it is not.
On search: reading time is not a ranking factor, and there is no documented ranking signal for how long visitors stay on a page, despite how often that is asserted. The label is a user-experience decision, not an optimisation.
The estimate describes how long the text would take to read completely. Analytics measure something different — how long a browser tab was open, sampled imperfectly — and the two rarely agree. Widely reported analyses of scroll behaviour suggest most visitors to a long article never reach its halfway point, so a ten-minute estimate and a two-minute average session are both plausibly correct descriptions of the same page.
If your real goal is helping people through long content, a scroll progress indicator does more than a number at the top, because it updates as they go rather than making a prediction at the start.
Languages without spaces. Chinese, Japanese and Thai do not delimit words with spaces, so a word count is either wrong or requires segmentation. Reading rate in those languages is measured in characters per minute, and the two units are not interchangeable — a word-based estimator applied to them produces numbers with no meaning.
Languages with very different word length. German compounds and the long agglutinated forms of Finnish, Turkish and Hungarian pack more meaning into fewer words, so a word-based count understates reading time. Translating an article typically changes its word count by ten to thirty percent without changing what it says, which is enough to move the label a whole minute.
Screen reader users. Many listen at rates well above typical silent reading — several hundred words per minute is common and experienced users go considerably faster. A visual reading-time estimate does not describe their experience of the page at all.
Show a read time on long-form articles where the commitment is real; skip it on short posts, where it adds a number without adding information. Put it near the title where the decision is being made. Count the article body only. Round to whole minutes and prefer about or a range over false precision. Keep the divisor consistent across your site so readers learn what your labels mean, and pick something near 240 for general non-fiction rather than an optimistic 300.
Around 238 words per minute for general non-fiction is the best-supported default. Lower it for technical or academic writing; the exact figure matters less than using the same one everywhere.
Yes, if your articles contain many of them. A per-image allowance and a slower rate for code lines both improve the estimate more than fine-tuning the words-per-minute figure.
No. It is not a ranking factor. It may improve how readers decide, which is a different and better reason to do it.
No. Counting and estimating happen in your browser. Nothing is uploaded, logged or retained, so drafts stay private.
" }, "loan-emi": { "title": "Loan EMI Calculator — See the Real Interest You Will Pay", "description": "Work out the monthly EMI on any loan, then see the full amortisation: how much of each payment is interest, how much kills the principal, and what the loan costs in total.", "keywords": "loan emi calculator, emi formula, monthly instalment calculator, home loan emi, car loan emi, amortisation schedule, total interest paid", "article": "EMI — Equated Monthly Instalment — is the fixed amount you pay each month on a loan. The number looks simple on a bank's website, but behind it sits a formula that determines how much of each payment goes to interest versus principal, how much total interest you will pay over the loan's lifetime, and whether you can afford the commitment.
\n\nEMI = P × r × (1+r)^n / ((1+r)^n − 1)
Where P = principal loan amount, r = monthly interest rate (annual rate ÷ 12), and n = number of monthly instalments.
\n\n| Parameter | Value |
|---|---|
| Principal (P) | $250,000 |
| Annual interest rate | 6.5% |
| Monthly rate (r) | 0.005417 |
| Tenure (n) | 30 years (360 months) |
| EMI | $1,580 |
| Total amount paid | $568,861 |
| Total interest paid | $318,861 |
You pay more in interest ($318,861) than the original loan amount ($250,000). This surprises most borrowers and is the single most important insight the EMI calculator provides.
\n\nIn the early years, most of the EMI goes to interest. In the later years, most goes to principal. For the $250,000 example above:
\n| Month | EMI | Interest portion | Principal portion | Remaining balance |
|---|---|---|---|---|
| 1 | $1,580 | $1,354 | $226 | $249,774 |
| 60 (Year 5) | $1,580 | $1,273 | $307 | $234,447 |
| 180 (Year 15) | $1,580 | $966 | $614 | $177,832 |
| 300 (Year 25) | $1,580 | $424 | $1,156 | $76,848 |
| 360 (Year 30) | $1,580 | $9 | $1,571 | $0 |
| Tenure | EMI | Total interest | Savings vs. 30 years |
|---|---|---|---|
| 30 years | $1,580 | $318,861 | — |
| 25 years | $1,691 | $257,278 | $61,583 |
| 20 years | $1,864 | $197,388 | $121,473 |
| 15 years | $2,178 | $141,998 | $176,863 |
Shortening the tenure from 30 to 20 years increases the EMI by $284 per month but saves $121,473 in total interest. This trade-off is the central decision in mortgage planning.
\n\nExtra monthly payment: Adding $200 per month to the EMI on the 30-year loan above reduces the tenure by 6.5 years and saves approximately $95,000 in interest.
\nAnnual lump sum: Making one extra EMI payment per year (13 payments instead of 12) reduces a 30-year mortgage to approximately 25.5 years.
\nBi-weekly payments: Paying half the EMI every two weeks results in 26 half-payments = 13 full payments per year, achieving the same effect as the annual lump sum strategy.
\n\nFixed-rate loans lock the interest rate for the entire tenure, making the EMI predictable. Floating-rate loans adjust periodically (usually quarterly or semi-annually) based on a benchmark rate. Floating rates are typically 0.5–1.5% lower initially but carry the risk of rising. In a falling-rate environment, floating saves money; in a rising-rate environment, fixed provides protection.
\n\nDoes prepaying a loan always save money?
Almost always, but check for prepayment penalties. Some fixed-rate loans charge 1–3% of the prepaid amount in the first few years. Calculate whether the penalty exceeds the interest savings.
Which loans should I pay off first?
Pay off the highest interest rate loan first (the \"avalanche\" method). This minimises total interest. The alternative — paying off the smallest balance first (the \"snowball\" method) — is psychologically satisfying but mathematically inferior.
How much EMI can I afford?
Financial advisors recommend that total EMI obligations (all loans) should not exceed 35–40% of net monthly income. Above 50%, the risk of financial stress increases significantly.
A tip calculator does simple arithmetic — multiply the bill by a percentage, optionally split it among diners — but tipping itself is anything but simple. Customs vary dramatically by country, by service type, and even by generation within the same city. Understanding the context matters as much as the calculation.
\n\n| Calculation | Formula | Example ($85 bill, 20%, 4 people) |
|---|---|---|
| Tip amount | Bill × Tip % | $85 × 0.20 = $17.00 |
| Total with tip | Bill + Tip | $85 + $17 = $102.00 |
| Per person (equal split) | Total / Diners | $102 / 4 = $25.50 |
In the US, bills show a subtotal (before tax) and a total (after tax). Etiquette experts and the Emily Post Institute recommend tipping on the pre-tax subtotal, but in practice most people tip on the post-tax total because it is the number they see. The difference on a $100 meal with 8.5 percent sales tax is $1.70 at a 20 percent tip — noticeable over a year of dining out, but not a social faux pas either way.
\n\n| Country | Restaurant tip | Notes |
|---|---|---|
| United States | 18–25% | Servers earn $2.13–$7.25/hour base; tips are primary income |
| Canada | 15–20% | Similar to US; rising with tap-to-pay prompts |
| United Kingdom | 10–15% or service charge | Many restaurants add 12.5% automatically |
| France | Round up or 5–10% | Service compris (included) is standard |
| Germany | 5–10% | Round up to the nearest euro or add 10% |
| Japan | 0% | Tipping is considered rude in most settings |
| Australia | 0–10% | Not expected; minimum wage is high |
| India | 5–10% | Higher in tourist areas; some add service charge |
Tipping is a $66 billion annual transfer in the United States alone (Bureau of Labor Statistics, 2023 estimate). Economists have debated its efficiency for decades. Arguments for tipping include direct performance incentives and the ability for customers to reward exceptional service. Arguments against include income volatility for workers, racial and gender bias in tip allocation (documented in multiple peer-reviewed studies), and the fact that most customers tip a fixed percentage regardless of service quality.
\n\nThe rise of tablet-based point-of-sale systems (Square, Toast, Clover) has introduced tip prompts in contexts where tipping was historically uncommon: coffee shops, fast-casual counters, food trucks, and even self-checkout kiosks. A 2023 Bankrate survey found that 66 percent of Americans have a negative view of tipping culture and feel pressured by screen prompts. The phenomenon is called \"tipflation\" — the perception that expected tip percentages are rising across all service categories.
\n\nFor a 20% tip: move the decimal point one place left (that gives 10%), then double it. For $85: 10% = $8.50, doubled = $17.00. For 15%: calculate 10% ($8.50) plus half of that ($4.25) = $12.75. For 25%: calculate 10% ($8.50) times 2.5 = $21.25, or simply add a quarter of the bill.
\n\nEqual splits are mathematically simple but socially fraught when one person ordered a salad and another ordered lobster. Two alternatives: split by item (each person tips on their own subtotal) or use the \"order-weighted\" method where each person's share is proportional to their order total. The Gen Code Tools tip calculator supports both approaches.
\n\nShould I tip on alcohol?
In the US and Canada, yes — tip on the full bill including drinks. In countries where service is included, no additional tip on alcohol is expected.
What if the service is genuinely poor?
In tipping cultures, leaving no tip sends a message but also harms the server financially. A better approach is to tip 10–15% and speak directly to management about the issue. Leaving nothing is reserved for truly egregious situations.
Do I tip on takeout?
Pre-2020, tipping on takeout was uncommon. Post-pandemic, 10–15% on takeout orders has become more common in the US, reflecting the additional packaging and coordination labour involved.
Unit conversion is the most frequently performed calculation on the internet. Every traveller, student, engineer, and home cook encounters it. The arithmetic is multiplication or division by a conversion factor, but knowing which factor and in which direction is where mistakes happen — especially when converting between metric and imperial systems that use fundamentally different base units.
\n| Category | From | To | Multiply by |
|---|---|---|---|
| Length | inches | centimetres | 2.54 |
| Length | feet | metres | 0.3048 |
| Length | miles | kilometres | 1.60934 |
| Weight | pounds | kilograms | 0.453592 |
| Weight | ounces | grams | 28.3495 |
| Volume | US gallons | litres | 3.78541 |
| Volume | UK gallons | litres | 4.54609 |
| Temperature | °F | °C | (°F − 32) × 5/9 |
| Area | acres | hectares | 0.404686 |
| Speed | mph | km/h | 1.60934 |
The metric system was adopted during the French Revolution (1795) and is now used by every country except the United States, Myanmar, and Liberia. The US attempted metrication in 1975 with the Metric Conversion Act, but made it voluntary. Without mandatory adoption, industries adopted selectively: science and medicine use metric; construction, cooking, and everyday life remain imperial.
\nThe result is that Americans routinely need to convert units when following international recipes, reading scientific papers, travelling abroad, or purchasing imported goods. The rest of the world primarily converts when consuming American content.
\nUS vs. UK gallons: A US gallon is 3.785 litres; a UK (imperial) gallon is 4.546 litres — 20% larger. Fuel economy figures (MPG) are not comparable across the Atlantic without adjusting for this difference.
\nTroy vs. avoirdupois ounces: Gold and precious metals are weighed in troy ounces (31.1g); everyday items use avoirdupois ounces (28.35g). A \"one-ounce\" gold coin is heavier than a food item listed as one ounce.
\nNautical vs. statute miles: A nautical mile is 1.852 km (based on one minute of latitude); a statute mile is 1.609 km. Aviation and maritime navigation use nautical miles exclusively.
\n| From | To | Factor |
|---|---|---|
| Kilobytes (KB) | Megabytes (MB) | ÷ 1,024 |
| Megabytes (MB) | Gigabytes (GB) | ÷ 1,024 |
| Gigabytes (GB) | Terabytes (TB) | ÷ 1,024 |
| Megabits (Mb) | Megabytes (MB) | ÷ 8 |
The SI prefix \"kilo\" means 1,000, but in computing, storage manufacturers use 1,000 (decimal) while operating systems use 1,024 (binary). A \"500 GB\" hard drive shows as approximately 465 GB in Windows because of this discrepancy. The IEC standard introduced unambiguous prefixes — kibibyte (KiB), mebibyte (MiB) — but adoption outside technical documentation remains limited.
\nBaking is the most conversion-sensitive cooking application because ratios must be precise. Professional bakers weigh ingredients in grams; home recipes in the US use volume measures (cups, tablespoons). Key conversions: 1 cup flour ≈ 125g, 1 cup sugar ≈ 200g, 1 cup butter ≈ 227g, 1 tablespoon ≈ 15ml. These vary by ingredient density, which is why weight-based measurement is more accurate.
\nWhy does the converter show so many decimal places?
Conversion factors are exact or very precise ratios. Displaying 4–6 significant figures ensures accuracy for engineering and scientific use. For everyday use, round to the nearest whole number or one decimal place.
Are conversion factors exact?
Some are exact by definition: 1 inch = exactly 2.54 cm, 1 pound = exactly 0.45359237 kg. Others are rounded approximations of measured physical constants.
Can I convert currency here?
No — currency conversion requires live exchange rates that fluctuate by the second. This tool handles physical units with fixed conversion factors only.
Temperature is the most converted physical quantity in everyday life. Travellers convert Fahrenheit to Celsius; scientists convert to Kelvin; engineers occasionally encounter Rankine. The formulas are simple algebra, but the history behind each scale explains why they exist and why converting between them is not as intuitive as converting metres to feet.
\n\n| Scale | Zero point | Boiling point of water | Absolute zero | Primary use |
|---|---|---|---|---|
| Celsius (°C) | Freezing point of water (0°C) | 100°C | −273.15°C | Most of the world, science |
| Fahrenheit (°F) | Brine freezing point (0°F) | 212°F | −459.67°F | United States, some Caribbean nations |
| Kelvin (K) | Absolute zero (0 K) | 373.15 K | 0 K | Physics, chemistry, engineering |
| From → To | Formula | Example |
|---|---|---|
| °C → °F | (°C × 9/5) + 32 | 100°C → 212°F |
| °F → °C | (°F − 32) × 5/9 | 72°F → 22.2°C |
| °C → K | °C + 273.15 | 25°C → 298.15 K |
| K → °C | K − 273.15 | 0 K → −273.15°C |
| °F → K | (°F − 32) × 5/9 + 273.15 | 32°F → 273.15 K |
Daniel Fahrenheit designed his scale in 1724 using three reference points: 0°F was the temperature of a brine solution (the coldest he could reliably produce), 32°F was the freezing point of water, and 96°F was human body temperature (later corrected to 98.6°F). The scale was practical for 18th-century meteorology because it avoided negative numbers in most European winter temperatures and provided finer resolution than Celsius — one Fahrenheit degree is 5/9 of a Celsius degree.
\n\n°C to °F (approximate): Double the Celsius value and add 30. This gives 100°C → 230°F (actual: 212°F) — rough but useful for everyday ranges. Between 0–40°C, the error is under 5°F.
\nThe crossover point: −40° is the same in both Celsius and Fahrenheit. This is the only intersection of the two scales and a useful mnemonic anchor.
\nBody temperature benchmark: 37°C = 98.6°F. Room temperature: 20–22°C = 68–72°F. Comfortable swimming pool: 26–28°C = 79–82°F.
\n\n| Context | °C | °F | K |
|---|---|---|---|
| Absolute zero | −273.15 | −459.67 | 0 |
| Antarctic winter | −50 | −58 | 223 |
| Water freezes | 0 | 32 | 273 |
| Room temperature | 21 | 70 | 294 |
| Human body | 37 | 98.6 | 310 |
| Water boils | 100 | 212 | 373 |
| Oven baking | 180 | 356 | 453 |
| Surface of the Sun | 5,500 | 9,932 | 5,773 |
Recipes from British, Australian, and European sources use Celsius. American recipes use Fahrenheit. The most common conversions: 180°C = 350°F (moderate oven), 200°C = 400°F (hot oven), 220°C = 425°F (very hot). Gas mark conversions add another layer: Gas Mark 4 = 180°C = 350°F.
\n\nKelvin is the SI unit of temperature and the only scale where zero means the complete absence of thermal energy. This makes it essential for thermodynamic calculations: the ideal gas law (PV = nRT) requires temperature in Kelvin. Using Celsius in the equation produces wrong results because the scale has an arbitrary zero point.
\n\nWhy does the US still use Fahrenheit?
The US attempted to switch to metric in the 1970s (Metric Conversion Act, 1975) but the transition stalled due to public resistance and lack of mandatory enforcement. Fahrenheit remains the default for weather, cooking, and medical use.
Is there a temperature below absolute zero?
In classical thermodynamics, no. In quantum mechanics, negative absolute temperatures exist in specific systems (population-inverted lasers), but these are \"hotter\" than any positive temperature — the concept does not mean \"colder than zero.\"
Which scale is most precise?
All three scales have the same precision when expressed to the same number of decimal places. Fahrenheit has smaller degrees (1°F = 0.556°C), which gives slightly finer resolution without decimals, but this is rarely a practical advantage.
The most widely used clinical rule of thumb is roughly 30 to 40 ml of total water per kilogram of body weight per day for a healthy adult in a temperate climate. Taking the middle of that range, a 70 kg adult lands on 70 × 35 = 2,450 ml, or about 2.5 litres of total water.
The word total is doing a lot of work there. Total water includes everything: plain water, tea, coffee, milk, juice, soup, and the water content of solid food. Roughly 20 to 30% of daily water intake comes from food — fruit and vegetables are 80 to 95% water, and even bread is around 35%. So a 2,450 ml total target means drinking closer to 1,800 to 2,000 ml. Calculators that hand you a total and imply you must drink all of it are overshooting by about a fifth.
For comparison, the US Institute of Medicine set adequate total water intake at about 3.7 litres a day for men and 2.7 for women, again including food. Those are population averages for planning, not individual prescriptions.
Eight eight-ounce glasses is 1.9 litres, and the figure is repeated everywhere without a source. The likely origin is a 1945 US National Research Council recommendation of about 1 ml of water per calorie consumed — which for a 2,000 calorie diet gives 2 litres. But that document explicitly added that most of this quantity is contained in prepared foods. The caveat was dropped somewhere in the retelling and the number became a drinking target. There is no controlled trial establishing eight glasses as a threshold for health.
| Factor | Rough adjustment | Why |
|---|---|---|
| Moderate exercise | +400 to 800 ml per hour | Sweat losses of 0.5 to 2 L per hour depending on intensity |
| Hot or humid climate | +500 to 1,000 ml | Higher baseline sweat rate even at rest |
| High altitude above 2,500 m | +300 to 500 ml | Increased respiratory water loss and diuresis |
| Fever, vomiting, diarrhoea | Substantially more | Losses can outpace thirst; oral rehydration salts may be needed |
| Pregnancy | +300 ml | Increased plasma volume |
| Breastfeeding | +700 to 1,000 ml | Milk is about 87% water |
| High-protein or high-fibre diet | Modestly more | Greater renal solute load; fibre binds water in the gut |
Your kidneys regulate hydration far more precisely than a weight-based estimate can. Two signals are worth more than the number this tool gives you:
This deserves stating plainly because most hydration content omits it. Drinking far beyond your needs, especially quickly, can dilute blood sodium and cause hyponatraemia, which ranges from headache and nausea to seizures and is occasionally fatal. Documented cases cluster in marathon runners who drank plain water heavily during long events, in some water-drinking challenges, and in people with kidney, heart or liver conditions or on certain medications. Healthy kidneys can excrete roughly 0.8 to 1 litre per hour, so sustained intake above that is the danger zone. If you are exercising for more than about 90 minutes, replacing electrolytes as well as water matters more than volume alone.
This is a general-population starting point built on body weight and a few adjustments. It cannot account for your kidney function, heart or liver condition, medications such as diuretics or lithium, sweat sodium concentration, or an actual measured sweat rate. If you have a diagnosed condition affecting fluid balance, or you have been given a fluid restriction, follow your clinician rather than a web calculator. Nothing here is medical advice.
Not at habitual doses. Caffeine is a mild diuretic, but the water in the drink more than compensates, and regular consumers develop tolerance to the diuretic effect. Coffee and tea count toward your intake.
Modestly, and indirectly. Water has no calories, so replacing sweetened drinks with it cuts intake, and a glass before a meal can slightly reduce how much people eat. Water itself does not burn fat.
For exercise, yes — it is the most practical method available. Weigh yourself before and after a session; each kilogram lost is roughly one litre of sweat. Replacing about 125 to 150% of that over the following hours restores balance.
No. Your weight and activity level are used only in your browser to compute the estimate, and nothing is transmitted or saved.
" }, "macro-calculator": { "title": "Macro Calculator — Protein, Fat and Carbs From Your Actual Numbers", "description": "Work out daily calories with the Mifflin-St Jeor equation, then split them into protein, fat and carbohydrate using evidence-based ranges, with a full worked example.", "keywords": "macro calculator, macronutrient split, mifflin st jeor, tdee calculator, protein per kg, cutting macros, bulking macros, iifym", "article": "A macro calculator converts a daily calorie target into grams of protein, carbohydrates, and fat based on your goals (weight loss, maintenance, or muscle gain). The three macronutrients provide all dietary energy: protein and carbs at 4 calories per gram, fat at 9 calories per gram. The ratio you choose affects body composition, satiety, exercise performance, and adherence.
\n| Macronutrient | Calories per gram | Primary function |
|---|---|---|
| Protein | 4 | Muscle repair, enzyme production, satiety |
| Carbohydrates | 4 | Primary energy source, brain fuel, glycogen replenishment |
| Fat | 9 | Hormone production, cell membranes, fat-soluble vitamin absorption |
| Alcohol | 7 | No nutritional function; metabolised as priority fuel |
| Goal | Protein | Carbs | Fat | Rationale |
|---|---|---|---|---|
| Weight loss | 30–35% | 35–40% | 25–30% | Higher protein preserves muscle and increases satiety |
| Maintenance | 25–30% | 40–50% | 25–30% | Balanced for sustained energy and health |
| Muscle gain | 25–30% | 45–55% | 20–25% | Higher carbs fuel training; adequate protein supports hypertrophy |
| Keto / low-carb | 20–25% | 5–10% | 65–75% | Very low carbs force ketosis; high fat provides primary fuel |
| Macro | % of calories | Calories | Grams |
|---|---|---|---|
| Protein (30%) | 660 | 660 ÷ 4 | 165g |
| Carbs (40%) | 880 | 880 ÷ 4 | 220g |
| Fat (30%) | 660 | 660 ÷ 9 | 73g |
The RDA for protein (0.8 g/kg/day) is the minimum to prevent deficiency, not the optimal amount for active individuals. A 2018 meta-analysis by Morton et al. in the British Journal of Sports Medicine found that 1.6 g/kg/day maximises muscle protein synthesis in resistance-trained adults. Beyond 2.2 g/kg/day, additional protein shows no further benefit in most studies.
\nFor a 75 kg person: RDA = 60g, optimal for training = 120g, upper useful limit ≈ 165g. The difference between minimum and optimal is substantial — and most casual dieters undereat protein.
\nIgnoring fibre: Fibre is a carbohydrate that is not fully digested. \"Net carbs\" (total carbs minus fibre) is a more accurate measure for low-carb dieters. A serving of vegetables might show 15g carbs but only 8g net carbs.
\nNeglecting micronutrients: Hitting macro targets with processed food is possible but nutritionally poor. 165g of protein from chicken breast is not the same as 165g from protein bars — the whole food delivers iron, B vitamins, and zinc alongside the protein.
\nObsessive precision: Tracking macros to the gram creates an unhealthy relationship with food for some people. Aiming within ±10% of targets is sufficient for results. Perfect adherence is unnecessary and often counterproductive.
\nDo I need to track macros to lose weight?
No — a calorie deficit is sufficient for weight loss regardless of macro composition. But tracking protein ensures you preserve muscle, and tracking carbs/fat helps identify overeating patterns.
Is a high-protein diet safe for kidneys?
For healthy individuals, yes — no evidence links high-protein diets (up to 2.2 g/kg) to kidney damage. People with pre-existing kidney disease should consult a doctor before increasing protein intake.
Should I adjust macros on rest days?
Some athletes reduce carbs by 10–20% on rest days and increase fat slightly, keeping protein constant. For most people, the difference is marginal — consistency across all days matters more than daily optimisation.
Calorie burn calculators estimate how many calories you expend during an activity based on your weight, the duration, and the activity's MET (Metabolic Equivalent of Task) value. The formula is standardised and used by every fitness tracker on the market — but the error margins are larger than most apps admit.
\nCalories Burned = MET × Weight (kg) × Duration (hours)
1 MET equals the energy cost of sitting quietly: approximately 1 kcal per kilogram of body weight per hour. An activity rated at 5 METs burns 5 times as much energy as sitting.
\n| Activity | MET value | Calories/hour (70 kg person) |
|---|---|---|
| Sitting (resting metabolic rate) | 1.0 | 70 |
| Walking (3 mph / 5 km/h) | 3.5 | 245 |
| Cycling (moderate, 12–14 mph) | 8.0 | 560 |
| Running (6 mph / 10 min/mile) | 9.8 | 686 |
| Swimming (moderate laps) | 7.0 | 490 |
| Weight training (general) | 3.5 | 245 |
| Yoga (Hatha) | 2.5 | 175 |
| HIIT | 8.0–12.0 | 560–840 |
| Cleaning house | 3.3 | 231 |
| Mowing lawn (push mower) | 5.5 | 385 |
MET values are population averages from the Compendium of Physical Activities (Ainsworth et al.), measured in laboratory settings with specific subjects. Your actual calorie burn varies based on:
\nThe typical error range for MET-based calorie estimates is ±15–20%. A reading of 500 calories could mean anywhere from 400 to 600 in reality.
\nA 2017 Stanford study found that the most accurate consumer wrist-worn devices had a median heart-rate error of 5% but a calorie-burn error of 27%. Chest-strap heart rate monitors combined with VO2 testing are more accurate but impractical for daily use. Treat tracker numbers as directional indicators, not precise measurements.
\nExcess Post-exercise Oxygen Consumption (EPOC) refers to the elevated calorie burn that continues after intense exercise. High-intensity interval training (HIIT) can produce EPOC effects lasting 12–38 hours, adding an estimated 6–15% to the session's calorie total. Steady-state cardio produces minimal EPOC. Most calorie calculators do not account for EPOC, making them slightly conservative for high-intensity activities.
\nDo I burn more calories if I weigh more?
Yes — the formula multiplies MET by body weight. A 90 kg person burns approximately 29% more calories than a 70 kg person performing the same activity for the same duration.
Is walking or running better for calorie burn?
Per unit of time, running burns more (9.8 vs. 3.5 METs). Per unit of distance, they are more similar — running a mile and walking a mile burn roughly 80–100 kcal, but running gets there faster.
Should I eat back the calories I burn?
Not fully — because the calorie estimate is likely 15–20% too high. Eating back 50–75% of exercise calories is a safer approach to avoid negating the deficit.
Four equations are in common use, all built as weight from height, and they give different answers for the same person. For a man of 175 cm — which is 68.9 inches, or 8.9 inches over five feet:
| Formula | Year | Rule for men | Result at 175 cm |
|---|---|---|---|
| Hamwi | 1964 | 48 kg + 2.7 kg per inch over 5 ft | 72.0 kg |
| Devine | 1974 | 50 kg + 2.3 kg per inch over 5 ft | 70.5 kg |
| Robinson | 1983 | 52 kg + 1.9 kg per inch over 5 ft | 68.9 kg |
| Miller | 1983 | 56.2 kg + 1.41 kg per inch over 5 ft | 68.8 kg |
A spread of 3.2 kg between formulas that are all called ideal. Now compare that to the healthy BMI range of 18.5 to 24.9, which at 1.75 m spans 56.7 kg to 76.3 kg — a window nearly 20 kg wide. Four different point estimates sitting inside one very broad healthy band is the clearest evidence that the precision implied by these formulas does not exist.
This is the fact that reframes everything. The Devine formula, the most cited of the four, was published in 1974 as a way to calculate drug doses — specifically to scale medications that distribute through lean tissue rather than fat, so that dosing an obese patient by total body weight would not overshoot. It was never validated as a health or aesthetic target. Hamwi came from a diabetes-education context for estimating calorie needs. Their survival as consumer ideal weight tools is an accident of convenience, not evidence.
They are still genuinely useful in clinical practice for ventilator tidal volume settings, chemotherapy dosing and renal function estimates. They are poor guides for what you should weigh.
Every one of these equations takes a single input. Things they cannot see:
If the actual question is health rather than a number on a chart, these are more informative and just as easy to take at home:
Use the figures on this page as a rough orientation point and nothing more. They do not apply to children or adolescents, to pregnant or breastfeeding women, to people with significant muscle mass or amputation, or to anyone with fluid retention from a heart, kidney or liver condition. A healthy weight for you is a conversation with a clinician who can see your body composition, history and blood work. This page is general information, not medical advice, and if weight is a source of anxiety or you have any history of disordered eating, a formula is the wrong tool entirely.
For orientation, none of them individually — look at the range they produce together, and check it against the healthy BMI band. If a clinician has asked you for ideal body weight for a dosing calculation, Devine is the usual convention.
Because average lean mass and body composition differ, the equations shift the baseline down by a few kilograms for women. It is a population average being applied to an individual, with all the imprecision that implies.
Usually not. BMI cannot distinguish muscle from fat, and it misclassifies muscular people routinely. Waist to height ratio is the better check in that situation.
No. Your height and sex are used only in your browser to run the four formulas, and nothing is transmitted or stored.
" }, "investment-return": { "title": "Investment Return Calculator — CAGR, Total Return and Real Return", "description": "Turn a start value and an end value into an annualised return with the CAGR formula, then adjust for inflation to see what the gain was actually worth.", "keywords": "investment return calculator, cagr formula, annualised return, real vs nominal return, total return, compound annual growth rate, inflation adjusted return", "article": "An investment return calculator takes a starting amount, an ending amount, and a time period, and computes the return. The simplest version is total return: (end − start) / start × 100%. But total return is misleading for comparing investments of different durations. A 50% return over 10 years is very different from a 50% return over 2 years. CAGR — Compound Annual Growth Rate — normalises for time.
\n| Metric | Formula | Use case |
|---|---|---|
| Total return | (End − Start) / Start × 100% | Single investment, single time period |
| CAGR | (End / Start)^(1/years) − 1 | Comparing investments of different durations |
| Annualised return | Same as CAGR for lump sums | Industry standard for fund performance |
| Real return | (1 + nominal) / (1 + inflation) − 1 | Purchasing power assessment |
| Detail | Investment A | Investment B |
|---|---|---|
| Initial investment | $10,000 | $10,000 |
| Final value | $15,000 | $18,000 |
| Holding period | 3 years | 7 years |
| Total return | 50% | 80% |
| CAGR | 14.47% | 8.78% |
Investment B has a higher total return but a lower annualised return. Investment A grew faster per year. CAGR makes this comparison fair.
\n| Asset class | Nominal CAGR (1926–2023) | Real CAGR (after inflation) |
|---|---|---|
| US large-cap stocks (S&P 500) | 10.1% | 6.9% |
| US small-cap stocks | 11.7% | 8.5% |
| Long-term government bonds | 5.2% | 2.2% |
| Treasury bills (cash equivalent) | 3.3% | 0.3% |
| Gold | 4.9% (1971–2023) | 1.8% |
| Inflation (CPI) | 3.0% | — |
A quick mental shortcut: divide 72 by the annual return to estimate how many years it takes to double your money. At 8% CAGR, money doubles in approximately 9 years. At 12%, approximately 6 years. The rule is accurate within ±1 year for returns between 4% and 20%.
\nThe SEC requires this disclaimer on all investment materials, and the data supports it. The S&P 500's 10-year annualised return has ranged from −3% (2000–2009) to +18% (2009–2019). Cherry-picking the start and end dates dramatically changes the result. The 97-year average of ~10% is meaningful for very long horizons (30+ years) but unreliable for any specific decade.
\nA 1% annual management fee seems small, but over 30 years on a $100,000 investment at 8% return, fees reduce the final balance from $1,006,266 to $761,226 — a $245,040 difference. Every percentage point of fees is a permanent drag that compounds alongside your returns. Index funds (0.03–0.10% fees) versus actively managed funds (0.50–1.50% fees) is the highest-impact financial decision most investors face.
\nShould I use nominal or real returns for planning?
Real (inflation-adjusted) returns for long-term goals like retirement. Nominal returns for comparing investment products, since fees and taxes are deducted from nominal returns.
What is a \"good\" return?
Context-dependent. A 7% real return is historically excellent for a diversified equity portfolio. A 4% real return is good for a balanced (60/40) portfolio. Anything promising consistent returns above 15% with low risk should be treated with extreme scepticism.
How do dividends affect the calculation?
Include reinvested dividends in the \"final value\" for total return. Many published index returns (e.g., S&P 500 \"total return\") include dividends; the \"price return\" version does not. The difference is approximately 2% per year.
Credit card interest is quoted annually but charged monthly. Divide by twelve to get the monthly rate: a 24% APR is 2% a month. On a 5,000 balance that is 100 of interest added every single month before any of your payment touches the principal.
The payoff period for a fixed monthly payment comes from the annuity formula rearranged for time:
Months = −ln(1 − r × P ÷ M) ÷ ln(1 + r)
where P is the balance, r the monthly rate and M your payment. The formula contains the whole story, because if r × P equals M, the logarithm is undefined — the debt never clears.
A balance of 5,000 at 24% APR:
| Monthly payment | Time to clear | Total paid | Interest paid |
|---|---|---|---|
| 100 | Never | Unlimited | Unlimited |
| 150 | 55 months, over 4.5 years | 8,321 | 3,321 |
| 200 | 35 months | 7,001 | 2,001 |
| 300 | 21 months | 6,145 | 1,145 |
| 500 | 12 months | 5,634 | 634 |
Look at the first row. Paying 100 a month on this balance is paying exactly the interest and nothing else — after ten years you would have handed over 12,000 and still owe 5,000. That is not a hypothetical; it is what happens whenever the payment equals the monthly interest charge.
Now look at the difference between 150 and 300. Doubling the payment does not halve the cost — it cuts the interest by two thirds and the time by nearly three quarters. Every extra unit above the interest charge attacks the principal directly, and the effect compounds. This is the single most useful thing to know about card debt.
Most issuers set the minimum as a small percentage of the balance plus that month accrued interest, often around 1% plus interest, with a floor of 25 or so. Because the percentage shrinks as the balance shrinks, the minimum falls too, and the payoff stretches out. On our 5,000 balance the first minimum would be about 150, and following the declining minimum for the whole life of the debt takes roughly 18 years and costs several times the original amount.
Card statements in many countries are now legally required to print how long the minimum payment will take, precisely because so few people worked it out. If your statement shows that line, read it.
With several cards, two strategies are commonly recommended and they optimise different things:
If the APR gap between your cards is large, avalanche wins clearly. If the balances are similar in cost, snowball is a reasonable choice.
A 0% transfer offer for 18 months with a 3% fee costs 150 on our 5,000 balance, against 3,321 of interest at 24% while paying 150 a month. The arithmetic is overwhelming — but only if you meet three conditions: you clear it, or nearly clear it, before the promotional rate expires; you do not put new spending on either card; and you do not miss a payment, which on most offers cancels the promotional rate immediately. Transfers fail as a strategy when they are used as breathing space rather than as a deadline.
This calculation assumes a fixed rate, a fixed payment, and no new spending. Real cards can have different rates for purchases, cash advances and transfers, and payments are typically allocated to the highest-rate balance first in some jurisdictions and the lowest in others. Penalty APRs after a missed payment can exceed 29%. Cash advances usually accrue interest from day one with no grace period. If your debt is unmanageable, a free non-profit debt counselling service can negotiate in ways a calculator cannot — that route is worth taking before any high-cost consolidation loan. Nothing here is financial advice.
Somewhat. Most cards compute interest on an average daily balance, so paying earlier in the cycle reduces that average and shaves a little interest. Paying twice a month rather than once has a small but real effect.
No. Lowering your utilisation ratio is one of the strongest positive factors. Keeping the account open with a zero balance is usually better for your score than closing it, since closing reduces your total available credit and can shorten average account age.
Generally yes, when the card rate far exceeds any interest your savings earn — 24% against 4% is not a close call. The usual exception is keeping a small emergency buffer, so an unexpected cost does not push you straight back onto the card.
No. The calculation runs entirely in your browser and nothing about your debt is transmitted or saved.
" }, "heart-rate-zones": { "title": "Heart Rate Zone Calculator — Karvonen Method, Done Properly", "description": "Calculate your five training zones from maximum and resting heart rate using the Karvonen reserve method, and see why the 220-minus-age rule is off by ten beats for most people.", "keywords": "heart rate zone calculator, karvonen formula, maximum heart rate, heart rate reserve, zone 2 training, tanaka formula, 220 minus age", "article": "Every zone calculation starts from an estimate of your maximum heart rate, and this is where most of the error enters. The three formulas in common use disagree, and all three are population averages:
| Formula | Equation | At age 35 |
|---|---|---|
| Fox, 1971 | 220 − age | 185 |
| Tanaka, 2001 | 208 − 0.7 × age | 184 |
| Gellish, 2007 | 207 − 0.7 × age | 183 |
The familiar 220 − age has no original research behind it — it was an informal fit to scattered data and was never validated. More importantly, its standard deviation is about 10 to 12 beats per minute. That means roughly a third of people have a true maximum more than 10 beats away from the estimate, and some are off by 20. Tanaka, derived from a large meta-analysis, is more accurate on average and notably better for people over 40, where 220 − age tends to underestimate.
The only reliable way to know your maximum is to measure it in a supervised graded exercise test, or to observe the highest value you have genuinely reached during an all-out effort. If you have such a number, use it and ignore the formulas.
Two people with the same maximum heart rate but resting rates of 45 and 75 are not working equally hard at 140 beats. The Karvonen method fixes this by working from heart rate reserve — the span between rest and maximum:
Target = resting HR + (intensity % × (max HR − resting HR))
Age 35, resting heart rate 60, using the Tanaka estimate of 184. Heart rate reserve is 184 − 60 = 124 beats.
| Zone | % of reserve | Beats per minute | What it is for |
|---|---|---|---|
| 1 — Recovery | 50 to 60% | 122 to 134 | Warm-up, cool-down, active recovery days |
| 2 — Aerobic base | 60 to 70% | 134 to 147 | Fat oxidation, mitochondrial density, the bulk of endurance volume |
| 3 — Tempo | 70 to 80% | 147 to 159 | Sustained moderate effort, aerobic capacity |
| 4 — Threshold | 80 to 90% | 159 to 172 | Lactate threshold work, race pace intervals |
| 5 — Maximum | 90 to 100% | 172 to 184 | Short intervals, VO2 max development |
This trips up a lot of people comparing numbers with a friend or a watch. The simpler percentage-of-maximum method would put 70% at 0.70 × 184 = 129 beats. Karvonen puts 70% of reserve at 147 beats — eighteen beats higher. Neither is wrong; they are different definitions of the same percentage. If a plan tells you to train at 70%, it matters enormously which method it means. Karvonen is generally preferred because it individualises for fitness, and a well-trained person with a resting rate of 45 gets appropriately different targets from a beginner at 80.
The most common training error is spending nearly all sessions in zone 3 — hard enough to be tiring, not hard enough to drive high-intensity adaptation, and too hard to accumulate real aerobic volume. Endurance athletes across sports converge on roughly 80% of training time in zones 1 and 2 with 20% in zones 4 and 5. Zone 2 should feel almost too easy: you can hold a full conversation. If you are breathing in short phrases, you have drifted into zone 3.
Heart rate is a signal about your whole physiological state, not just your effort. Expect it to move by 5 to 15 beats for reasons that have nothing to do with fitness:
These zones are built on an age-based population estimate with a known error of around 10 beats, then divided into bands whose boundaries are conventions rather than measured physiological thresholds. Your actual lactate threshold might sit anywhere in zone 3 or 4. Chest-strap monitors are reliable; wrist optical sensors lag during rapid changes and can lock onto cadence instead of pulse during running, producing convincingly wrong data. If you take heart medication, have a diagnosed cardiac condition, or are new to intense exercise after a long gap, get clearance from a clinician before training at zones 4 and 5. This page is general information, not medical advice.
Immediately on waking, before getting out of bed or looking at a phone, counted over a full 60 seconds — or read the overnight low from a wearable. Take an average across several mornings rather than one reading.
Check which method your watch uses. Many default to percentage of maximum, and many still use 220 − age. Most let you enter a measured maximum and switch to the reserve method, which is worth doing.
No. Maximum heart rate is largely genetic and declines with age regardless of training. Fitness shows up as a lower resting rate, faster recovery after effort, and more speed at the same heart rate.
No. Your age and resting rate are used only in your browser to compute the zones; nothing is transmitted or saved.
" }, "timestamp-converter": { "title": "Unix Timestamp Converter — Epoch Time, Milliseconds and the 2038 Problem", "description": "Convert Unix epoch timestamps to readable dates and back, tell seconds from milliseconds at a glance, and understand leap seconds, ISO 8601 and the 2038 overflow.", "keywords": "unix timestamp converter, epoch time converter, milliseconds to date, iso 8601, year 2038 problem, utc timestamp, leap seconds unix time", "article": "A Unix timestamp is the number of seconds (or milliseconds) since January 1, 1970, 00:00:00 UTC — the \"epoch.\" It is the universal time format in computing: databases, APIs, log files, and programming languages all use it internally. The timestamp converter translates between this machine-readable number and human-readable date formats.
\n| Format | Example | Used by |
|---|---|---|
| Unix seconds | 1695225600 | C, Python, PHP, Unix systems |
| Unix milliseconds | 1695225600000 | JavaScript, Java, Dart |
| ISO 8601 | 2023-09-20T16:00:00Z | APIs, JSON, XML, databases |
| RFC 2822 | Wed, 20 Sep 2023 16:00:00 +0000 | Email headers, HTTP headers |
| Human readable | September 20, 2023, 4:00 PM UTC | User interfaces |
Human-readable dates are ambiguous. \"01/02/03\" is January 2 in the US, February 1 in Europe, and February 3 in Japan. \"Next Tuesday\" depends on when you say it. A Unix timestamp is unambiguous: 1695225600 means exactly one moment in time, everywhere in the world, in every programming language. All localisation (timezone, date format, language) happens at the display layer.
\nUnix timestamps stored as 32-bit signed integers overflow on January 19, 2038, at 03:14:07 UTC. After this moment, a 32-bit timestamp wraps around to a negative number representing December 13, 1901. Modern systems use 64-bit timestamps (which overflow in the year 292,277,026,596 — effectively never), but legacy embedded systems, IoT devices, and older databases remain vulnerable. The 2038 problem is Y2K's less famous successor.
\nUnix timestamps are always in UTC. Converting to local time requires knowing the timezone offset and whether Daylight Saving Time (DST) is active. This is harder than it sounds:
\n| Timezone | UTC offset (standard) | UTC offset (DST) |
|---|---|---|
| US Eastern (ET) | UTC−5 | UTC−4 |
| US Pacific (PT) | UTC−8 | UTC−7 |
| Central European (CET) | UTC+1 | UTC+2 |
| India (IST) | UTC+5:30 | No DST |
| Japan (JST) | UTC+9 | No DST |
| Australia Eastern (AEST) | UTC+10 | UTC+11 |
DST transitions are not globally consistent: the US changes clocks in March/November; Europe changes in March/October; most of Africa and Asia do not observe DST at all. The IANA timezone database (tzdata) tracks these rules and is updated multiple times per year as governments change DST policies.
\nJavaScript's Date.now() returns milliseconds; Python's time.time() returns seconds with decimal fractions; databases vary. The converter auto-detects: if the number has 13 digits, it's milliseconds; 10 digits, it's seconds. Getting this wrong produces dates in the year 53,000 or 1970 — a common debugging headache.
What is the current Unix timestamp?
The converter shows the live current timestamp, updated every second. As of this writing, we are past timestamp 1,750,000,000 (reached June 2025).
Can timestamps be negative?
Yes — negative timestamps represent dates before the epoch (January 1, 1970). Timestamp −86400 is December 31, 1969. Most systems support this, but some JavaScript environments and databases do not handle negative timestamps correctly.
Why does my API return timestamps in milliseconds?
JavaScript convention. Since JavaScript is the dominant language for web APIs and its Date object uses milliseconds internally, many APIs follow suit. Always check the API documentation to confirm the unit.
A number base (or radix) is the number of unique digits used to represent values. Decimal uses 10 digits (0–9), binary uses 2 (0, 1), octal uses 8 (0–7), and hexadecimal uses 16 (0–9, A–F). Converting between bases is fundamental to computing, networking, and digital electronics — and the algorithm is the same regardless of the bases involved.
\n| Base | Name | Digits | Primary use |
|---|---|---|---|
| 2 | Binary | 0, 1 | CPU operations, digital logic |
| 8 | Octal | 0–7 | Unix file permissions (chmod 755) |
| 10 | Decimal | 0–9 | Human arithmetic, finance |
| 16 | Hexadecimal | 0–9, A–F | Memory addresses, colours (#FF5733), MAC addresses |
| 32 | Base32 | A–Z, 2–7 | Encoding (TOTP codes, Crockford encoding) |
| 64 | Base64 | A–Z, a–z, 0–9, +, / | Email attachments, data URIs, JWT tokens |
All conversions go through base 10 as an intermediate step:
\n| Decimal | Binary | Octal | Hex |
|---|---|---|---|
| 0 | 0000 | 0 | 0 |
| 5 | 0101 | 5 | 5 |
| 10 | 1010 | 12 | A |
| 15 | 1111 | 17 | F |
| 16 | 10000 | 20 | 10 |
| 255 | 11111111 | 377 | FF |
| 256 | 100000000 | 400 | 100 |
CSS colours like #FF5733 encode three 8-bit channels (Red, Green, Blue) as two hex digits each. FF = 255 (maximum red), 57 = 87 (moderate green), 33 = 51 (low blue). Hex is used because it maps directly to the 8-bit byte: one byte = 2 hex digits = 8 binary digits. Reading \"FF\" is faster than reading \"11111111\" and more compact than reading \"255\".
\nIP addresses (IPv4) are 32-bit binary numbers displayed in dotted decimal for readability. 192.168.1.1 is actually 11000000.10101000.00000001.00000001 in binary. Subnet masks are binary patterns that determine which bits identify the network and which identify the host. Understanding binary is essential for network configuration, CIDR notation, and troubleshooting.
\nWhat is the difference between 0x and 0b prefixes?
0x denotes hexadecimal (0xFF = 255), 0b denotes binary (0b11111111 = 255), and 0o denotes octal (0o377 = 255) in most programming languages. These prefixes prevent ambiguity — \"10\" means ten in decimal, two in binary, eight in octal, or sixteen in hex.
Can I convert fractions?
Yes, but fractional conversion can produce repeating patterns. 0.1 in decimal is 0.000110011... in binary (repeating), which is why floating-point arithmetic sometimes produces unexpected results like 0.1 + 0.2 = 0.30000000000000004.
What is base36?
Base36 uses 0–9 and A–Z (36 characters) and is used for URL shorteners and compact identifiers because it packs the most information per character using only alphanumeric characters.
A prime number is a natural number greater than 1 that has no positive divisors other than 1 and itself. The concept is elementary; the implications reach into cryptography, computer science, and one of the oldest unsolved problems in mathematics. This tool checks whether a given number is prime, lists its factors if it is not, and explains the algorithm used.
\nTrial division up to √n: divide n by every integer from 2 to √n. If any division produces zero remainder, n is composite. If none do, n is prime.
\n| Number | Divisions tested | Result |
|---|---|---|
| 17 | 17 ÷ 2, ÷ 3, ÷ 4 (√17 ≈ 4.1) | Prime |
| 51 | 51 ÷ 2, ÷ 3 = 17 → remainder 0 | Composite (3 × 17) |
| 97 | 97 ÷ 2 through ÷ 9 (√97 ≈ 9.8) | Prime |
| 1,000,003 | ÷ 2 through ÷ 1000 | Prime |
Time complexity: O(√n). For numbers up to 10^12, this completes in milliseconds. For larger numbers, probabilistic tests (Miller-Rabin) are used instead.
\n2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229.
\nRSA encryption — the algorithm that secures most internet commerce — relies on the fact that multiplying two large primes is easy but factoring the product is computationally infeasible. A 2048-bit RSA key uses two primes of approximately 300 digits each. Their product (the public key) can be freely shared; recovering the original primes (needed for the private key) would take billions of years with current technology.
\n| Problem | Statement | Status |
|---|---|---|
| Twin Prime Conjecture | There are infinitely many pairs of primes that differ by 2 (e.g., 11 and 13) | Unproven (Yitang Zhang proved a finite gap in 2013) |
| Goldbach's Conjecture | Every even integer > 2 is the sum of two primes | Verified up to 4×10^18; no proof |
| Riemann Hypothesis | All non-trivial zeros of the zeta function have real part 1/2 | Unproven; $1 million Millennium Prize |
| Type | Definition | Example |
|---|---|---|
| Mersenne prime | 2^p − 1 where p is prime | 2^31 − 1 = 2,147,483,647 |
| Twin primes | p and p+2 both prime | (41, 43) |
| Sophie Germain prime | p where 2p+1 is also prime | 23 (2×23+1 = 47 is prime) |
| Palindromic prime | Prime that reads same forwards and backwards | 131, 787, 11311 |
Is 1 a prime number?
No. By modern convention (since the early 20th century), 1 is excluded from the primes. This simplifies the Fundamental Theorem of Arithmetic, which states that every integer > 1 has a unique prime factorisation.
Is 2 the only even prime?
Yes. Every even number > 2 is divisible by 2, so 2 is the only even prime — and also the smallest prime.
How large is the largest known prime?
As of 2024, the largest known prime is 2^82,589,933 − 1, a Mersenne prime with 24,862,048 digits. It was discovered by the Great Internet Mersenne Prime Search (GIMPS), a distributed computing project.
The Greatest Common Divisor (GCD) and Least Common Multiple (LCM) are the two most fundamental operations in number theory. GCD(a, b) is the largest positive integer that divides both a and b without remainder. LCM(a, b) is the smallest positive integer that both a and b divide into without remainder. Together, they appear in fraction arithmetic, gear ratios, scheduling problems, cryptography, and computer science.
\nGCD(a, b) × LCM(a, b) = a × b
This identity means you only need to compute one to get the other: LCM(a, b) = a × b / GCD(a, b). Since GCD is faster to compute (using Euclid's algorithm), this is how every calculator derives LCM in practice.
The oldest known algorithm still in daily use. The idea: GCD(a, b) = GCD(b, a mod b), repeated until the remainder is zero. The last non-zero remainder is the GCD.
\n| Step | a | b | a mod b |
|---|---|---|---|
| 1 | 252 | 105 | 42 |
| 2 | 105 | 42 | 21 |
| 3 | 42 | 21 | 0 |
GCD(252, 105) = 21. The algorithm runs in O(log(min(a, b))) time, making it efficient even for very large numbers — including the 2048-bit integers used in RSA encryption.
\n| Number | Prime factors |
|---|---|
| 252 | 2² × 3² × 7 |
| 105 | 3 × 5 × 7 |
| GCD | 3¹ × 7¹ = 21 (take minimum exponents) |
| LCM | 2² × 3² × 5 × 7 = 1260 (take maximum exponents) |
This method is intuitive and useful for teaching, but impractical for large numbers because prime factorisation is computationally expensive (no known polynomial-time algorithm for general integers, which is the basis of RSA security).
\nFraction simplification: To simplify 252/105, divide both by GCD(252, 105) = 21, yielding 12/5. Every fraction-simplification operation implicitly computes a GCD.
\nScheduling problems: Two events recur every 12 and 18 days. When do they next coincide? LCM(12, 18) = 36 days. This extends to bus schedules, maintenance cycles, and production line synchronisation.
\nGear ratios: A gear with 42 teeth meshing with a gear with 28 teeth has a ratio of 42:28 = 3:2 (simplified by GCD = 14). The LCM determines how many rotations before the same teeth re-engage — critical for wear distribution.
\nCryptography: RSA key generation uses Euler's totient function, which relies on GCD. The extended Euclidean algorithm computes modular inverses needed for decryption.
\nMusic and rhythm: A polyrhythm of 3 against 4 repeats every LCM(3, 4) = 12 beats. African drumming and progressive rock exploit polyrhythmic patterns extensively.
\nGCD is associative: GCD(a, b, c) = GCD(GCD(a, b), c). This allows chaining for any number of inputs. The same applies to LCM.
\nGCD(0, n) = n (by convention). GCD(0, 0) is undefined (every integer divides 0). LCM(0, n) = 0 (by convention in most implementations). Negative numbers: GCD is always positive; use absolute values.
\nWhat is the difference between GCD and HCF?
They are the same thing. HCF (Highest Common Factor) is the term used in British and Indian mathematics education; GCD (Greatest Common Divisor) is the American and international standard.
Can GCD be computed for non-integers?
Not directly. GCD is defined for integers. For rational numbers, you can compute GCD of the numerators after finding a common denominator, but this is uncommon outside specialised mathematics.
Why is Euclid's algorithm so fast?
Each step reduces the larger number by at least half (a mod b < a/2 when a > b). This guarantees logarithmic convergence — even for numbers with thousands of digits, the algorithm completes in milliseconds.
A ratio expresses the relative size of two or more quantities. 3:2 means that for every 3 units of the first quantity, there are 2 of the second. Ratios appear in cooking recipes, aspect ratios, financial analysis, map scales, and probability — and simplifying or scaling them is one of the most common mathematical operations in daily life.
\n| Operation | Input | Output | Method |
|---|---|---|---|
| Simplify | 12:8 | 3:2 | Divide both by GCD (4) |
| Scale up | 3:2, scale to 15 | 15:10 | Multiply both by 5 |
| Find missing value | 3:2 = ?:10 | 15:10 | Cross-multiply: ? = 3×10/2 = 15 |
| Convert to fraction | 3:2 | 3/2 or 1.5 | Divide first by second |
| Convert to percentage | 3:2 (of total) | 60%:40% | Each part ÷ sum × 100 |
| Ratio | Context |
|---|---|
| 16:9 | Widescreen video and monitor aspect ratio |
| 4:3 | Traditional TV and iPad aspect ratio |
| 1:1.618 | Golden ratio (φ), used in design and architecture |
| 3:1 | Concrete mix (cement : sand : gravel = 1:2:3 → water:cement ≈ 0.5:1) |
| 1:50,000 | Topographic map scale (1 cm = 500 m) |
| 2:1 | Standard cocktail spirit-to-mixer ratio |
Screen aspect ratios define the width-to-height relationship. A 16:9 screen with a width of 1920 pixels has a height of 1920 × 9/16 = 1080 pixels (Full HD). A 21:9 ultrawide at 3440 pixels wide has a height of 3440 × 9/21 = 1474 pixels (approximately 1440). When you resize images or videos, maintaining the aspect ratio prevents distortion — scale both dimensions by the same factor.
\nProfessional bakers express recipes as ratios rather than absolute quantities because ratios scale linearly. A basic bread dough is flour:water:salt:yeast = 100:65:2:1 (by weight). To make twice as much, double every number. This is why baking by weight is more reliable than baking by volume — ratios preserve the chemistry regardless of batch size.
\nInvestors use dozens of ratios to evaluate companies: P/E (price-to-earnings), debt-to-equity, current ratio (current assets / current liabilities). A P/E of 15:1 means investors pay $15 for every $1 of earnings. These ratios are only meaningful in context — a P/E of 30 is expensive for a utility company but normal for a high-growth tech company.
\nThe golden ratio (φ ≈ 1.618) appears in nature (sunflower seed spirals, nautilus shells), art (Parthenon proportions), and design (Apple's logo geometry). Whether its aesthetic properties are real or a confirmation bias is debated, but designers frequently use it for layout proportions: sidebar width = content width / 1.618.
\nIs 3:2 the same as 2:3?
No. Order matters. 3:2 means the first quantity is larger; 2:3 means the second is larger. When expressing ratios, maintain a consistent convention (e.g., width:height for screens).
Can ratios have more than two terms?
Yes. Concrete mix is expressed as 1:2:3 (cement:sand:gravel). Simplification divides all terms by their common GCD.
How do I convert a ratio to a decimal?
Divide the first number by the second. 3:2 = 3/2 = 1.5. For multi-term ratios, express each term as a fraction of the total: 1:2:3 totals 6, so the parts are 1/6, 2/6, 3/6 (≈ 16.7%, 33.3%, 50.0%).
A year contains 52.1786 weeks — that is 365.25 days divided by 7. So a 90-year life is 4,696 weeks, and someone who has just turned 35 has lived 1,826 of them, with roughly 2,870 left if they reach 90.
The reason to use weeks rather than years is that they are small enough to feel countable and large enough to matter. Nobody has an intuition for 19,710 days. But 4,696 boxes fits on one sheet of paper, and 2,870 remaining feels like a finite quantity in a way that 55 years does not. The unit is doing the work here, not the maths.
| Age now | Weeks lived | Weeks to 80 | Weeks to 90 |
|---|---|---|---|
| 20 | 1,044 | 3,131 | 3,653 |
| 30 | 1,565 | 2,609 | 3,131 |
| 40 | 2,087 | 2,087 | 2,609 |
| 50 | 2,609 | 1,565 | 2,087 |
| 60 | 3,131 | 1,044 | 1,565 |
| 70 | 3,653 | 522 | 1,044 |
Total weeks remaining is interesting once. The figures that tend to land harder are the ones scoped to a specific relationship or activity, because those clocks run out long before your own does:
This is the genuine use of the calculation. It does not add time; it makes the allocation visible.
The number this tool projects to is a placeholder, not a forecast, and it is worth being clear about the gap. Global average life expectancy at birth is around 73 years, but the spread by country is enormous — roughly 84 in Japan, 81 in Western Europe, 79 in the United States, 67 in Pakistan. Within any country, differences by income, education and postcode routinely run to a decade.
Three technical caveats that most life-expectancy content skips:
None of this is medical or actuarial advice. Choose a number you find useful to think against — 80, 90, 100 — and treat the grid as a framing device rather than a countdown.
Two honest criticisms of the whole life-in-weeks genre, which is usually presented without them.
First, it can produce anxiety rather than clarity. Seeing thousands of filled boxes provokes a sense of waste in people who have not wasted anything. Weeks spent recovering from illness, raising small children, or simply resting are not lost weeks, but a grid renders them identically to any other.
Second, it implies every week is equally available and equally valuable. They are not. A week at 35 with a mortgage and a job is not interchangeable with a week at 22 or a week at 70. Optimising for the count misses that.
The framing works best as an occasional recalibration — a reason to make one specific decision differently — and worst as a daily metric.
Because 52 × 7 is 364, so using a flat 52 loses more than a day a year and drifts by over a month across a lifetime. The 0.1786 accounts for the extra day plus leap years.
It circulated widely after Tim Urban published a life-in-weeks grid on Wait But Why, though the underlying idea is much older — memento mori as a deliberate practice goes back to Stoic philosophy, and Psalm 90 asks to be taught to number one days.
Many people do, and mark one box a week. The physical version seems to work better than a screen, probably because it stays visible without being refreshed. Whether that is motivating or oppressive is personal — try it for a month before committing to a wall.
No. Your date is used only in your browser to compute the numbers, and nothing is transmitted or saved.
" }, "year-progress": { "title": "Year Progress — How Far Through the Year You Actually Are", "description": "See the exact percentage of the year completed, with the day-of-year calculation worked through, leap year rules, and quarter and fiscal-year boundaries.", "keywords": "year progress, percentage of year completed, day of year calculator, days left in year, leap year rule, quarter progress, iso week number", "article": "The year progress bar shows what percentage of the current year has elapsed. On July 1st, it reads approximately 50%. On December 31st, 99.7%. The concept was popularised by the @year_progress Twitter bot (now 7.5 million followers) and has become a cultural touchstone for temporal awareness — a simple visual that provokes a surprisingly strong emotional response.
\nYear Progress = (Day of Year / Total Days in Year) × 100
| Date | Day of year | Progress (non-leap) |
|---|---|---|
| January 31 | 31 | 8.5% |
| March 31 | 90 | 24.7% |
| June 30 | 181 | 49.6% |
| September 30 | 273 | 74.8% |
| December 31 | 365 | 100.0% |
Psychologists identify the \"end-of-history illusion\" — people acknowledge that they have changed significantly in the past but predict that they will change relatively little in the future. The year progress bar is a corrective: it makes the passage of time visceral and immediate, countering the default assumption that \"there's plenty of time.\"
\nThe subjective speed of time changes with age. A widely cited proportional theory (attributed to Paul Janet, 1897) notes that each year is a smaller fraction of your total life experience as you age: a year is 10% of a 10-year-old's life but only 2% of a 50-year-old's. More recent research suggests that the effect is driven by the ratio of novel to familiar experiences — years filled with new experiences feel longer in retrospect, while routine years feel like they passed instantly.
\nAnnual goal tracking: If your year progress is at 50% but your goal progress is at 20%, the gap is visible and actionable. Pair the year progress bar with specific, measurable goals to convert temporal awareness into behavioural change.
\nBudget pacing: At 50% year progress, you should have approximately 50% of your annual budget remaining. Significant deviation in either direction indicates overspending or underspending relative to plan.
\nProject management: If a 12-month project is at 75% year progress but only 40% complete, the schedule risk is concrete and communicable. The progress bar makes abstract timeline gaps tangible for stakeholders.
\n| Milestone | Date | Year % |
|---|---|---|
| Q1 ends | March 31 | 24.7% |
| Q2 ends | June 30 | 49.6% |
| Q3 ends | September 30 | 74.8% |
| Q4 ends | December 31 | 100% |
| 100 days left | September 22 | 72.6% |
| Half year | July 2 (noon) | 50.0% |
The @year_progress bot's tweets consistently reach millions of impressions. When the bar crosses 25%, 50%, 75%, and 90%, the replies fill with expressions of shock, motivation, and existential reflection. The bar has become a meme format — people create personal progress bars, project progress bars, and satirical \"adulthood progress\" bars. Its power lies in its simplicity: a single number that requires no context to understand.
\nDoes the progress bar account for leap years?
Yes. In leap years (366 days), each day represents 0.273% instead of 0.274%. The difference is negligible for display purposes but is handled correctly in the calculation.
Can I set custom start and end dates?
The year progress bar uses January 1 to December 31. For fiscal years, academic years, or project timelines, adjust the start date in the tool settings.
Is there a psychological benefit to tracking year progress?
Research on implementation intentions (Gollwitzer, 1999) shows that people who monitor progress toward goals are significantly more likely to achieve them. The year progress bar is a low-friction monitoring tool that requires no manual input.
Counting the days between two dates should be straightforward subtraction, but calendars are messy. Months have different lengths, leap years add an extra day every four years (except every 100 years, except every 400 years), and the question of whether to include the start date or end date changes the answer by one. The days-until calculator handles all of this correctly.
\nDays Until = Target Date − Today
Both dates are converted to a continuous day count (Julian Day Number or Unix timestamp divided by 86,400), subtracted, and the remainder is the number of days. Timezone is relevant: \"today\" depends on where you are.
\n| Event | Typical date | Approximate days from Jan 1 |
|---|---|---|
| Valentine's Day | February 14 | 45 |
| US Tax Day | April 15 | 105 |
| Summer solstice | June 21 | 172 |
| Halloween | October 31 | 304 |
| Christmas | December 25 | 359 |
| New Year's Eve | December 31 | 365 |
From Monday to Friday: is that 4 days or 5? If you count both endpoints (inclusive), it's 5 calendar days. If you exclude the start date (the standard in computing and most legal contexts), it's 4 days. If you exclude both endpoints, it's 3 days. The difference matters for rental agreements, contract deadlines, and legal filings. The calculator defaults to excluding the start date (the most common convention).
\n| Rule | Example |
|---|---|
| Divisible by 4 → leap year | 2024, 2028 are leap years |
| Divisible by 100 → NOT a leap year | 1900 was not a leap year |
| Divisible by 400 → IS a leap year | 2000 was a leap year |
This means February 29 exists in 2024 but not in 2100. The Gregorian calendar's leap year rules keep the calendar year aligned with the solar year (365.2422 days) to within one day per 3,236 years.
\nMany deadlines are specified in business days (excluding weekends and holidays). 10 business days is 14 calendar days if there are no holidays in between — but could be 16+ calendar days if holidays fall within the period. The calculator offers both modes.
\nCountdown timers exploit the \"goal gradient effect\" (Hull, 1932): people accelerate effort as they approach a goal. Runners speed up in the final mile; savers increase deposits as their target approaches; students study harder as the exam date nears. A visible countdown converts abstract future deadlines into concrete urgency.
\nThe days-until calculation is the foundation of every project timeline. Sprint deadlines, release dates, and milestone reviews all depend on accurate day counting. Buffer time — the difference between the planned days and the actual days available — is the most underestimated variable in project planning. Research suggests adding 30–50% buffer to initial estimates to account for scope changes, dependencies, and unplanned work.
\nDoes the calculator handle dates across time zones?
It uses your local date. If your target event is in another timezone, adjust accordingly — a midnight event in Tokyo is still \"tomorrow\" in New York.
Can I count days between past dates?
Yes. Enter any two dates and the calculator returns the absolute number of days between them, regardless of whether they are in the past or future.
What about weeks, months, and years?
The calculator converts the day count into years, months, weeks, and days for readability. The conversion uses calendar counting (complete months, then remaining days), not fixed 30-day months.
Ask how long ago 15 March 2019 was, as of 28 August 2026, and there are two correct answers depending on the unit you choose:
\n| Duration | Days | Calendar expression |
|---|---|---|
| 1 year | 365 (or 366) | 12 months |
| 5 years | 1,826 (with 1 leap year) | 60 months |
| 10 years | 3,652 (with 2–3 leap years) | 120 months |
| 1 billion seconds | 11,574 days | 31 years, 8 months, 8 days |
The calendar form is what people want and where the difficulty lives, because months have different lengths. Converting 2,723 days by dividing by 30.44 gives 89.5 months, which is not the same as counting 89 calendar month boundaries and a remainder. Both are defensible; they produce different remainders.
The standard method — the one used for ages, service length and most legal purposes — counts complete years first, then complete months, then leftover days:
Result: 7 years, 5 months, 13 days. Notice that the answer depends on the order of operations. Counting months first and then years can give a different remainder for the same pair of dates, which is why two calculators sometimes disagree by a day or two on a long span.
The clearest illustration of why this is hard. How long from 31 January to 28 February?
Different systems answer differently. Most clamp to the last valid day, treating it as a complete month. Some treat it as 0 months and 28 days. Neither is a bug; the calendar is simply underdefined here. If you are calculating a notice period, an interest accrual or a subscription renewal that lands on a month end, check which rule your system applies rather than assuming.
Someone born on 29 February has a legal birthday that varies by jurisdiction. In much of the world it is treated as 1 March in non-leap years; in others, including parts of the UK for certain purposes, it is 28 February. This matters for coming-of-age thresholds, licence expiry and insurance. It is one of the few date questions where the correct answer genuinely depends on which country is asking.
The common cases are milestones and records rather than curiosity: how long since a job started, for a CV or a service-length calculation; how long since a quit date, where the day count is often more motivating than the calendar form; how long a relationship or a business has run, for an anniversary; and how long since a purchase, for a warranty claim. In the last case the day count is the one that matters, because warranty periods are usually specified in months from the date of purchase and the retailer will compute it their way.
Leap days. Over 35 years you accumulate eight or nine extra days, so the multiplication is short by more than a week.
Whichever the document specifies, and if it does not, give the exact start and end dates rather than a duration. A duration is a derived figure with conventions attached; two dates are facts.
Yes, if you have an exact start time. Be aware that precision beyond a day is only meaningful if the original timestamp was recorded that precisely, and that daylight saving affects hour counts.
No. The calculation runs in your browser and nothing is transmitted or saved.
" }, "sleep-debt": { "title": "Sleep Debt Calculator — How Much You Owe and How to Repay It", "description": "Track accumulated sleep debt against your actual need, and understand why one long weekend lie-in does not clear a week of short nights.", "keywords": "sleep debt calculator, sleep deficit, how much sleep do i need, catch up on sleep, chronic sleep restriction, sleep recovery", "article": "Sleep debt is the cumulative difference between the sleep you need and the sleep you actually get. One night of 6 hours when you need 8 creates a 2-hour debt. Five such nights create a 10-hour debt. The question that matters — and that the research has strong answers to — is whether and how you can repay it.
\nSleep Debt = Σ (Recommended Sleep − Actual Sleep) for each night
| Night | Recommended | Actual | Nightly debt | Cumulative debt |
|---|---|---|---|---|
| Monday | 8h | 6h | 2h | 2h |
| Tuesday | 8h | 5.5h | 2.5h | 4.5h |
| Wednesday | 8h | 7h | 1h | 5.5h |
| Thursday | 8h | 6h | 2h | 7.5h |
| Friday | 8h | 6.5h | 1.5h | 9h |
| Weekend (2 nights) | 8h | 10h each | −2h each | 5h |
Weekend catch-up sleep reduced the debt from 9 hours to 5 hours — but did not eliminate it. This pattern, repeated week after week, is how chronic sleep debt accumulates.
\n| Age group | Recommended hours |
|---|---|
| Newborns (0–3 months) | 14–17 |
| Infants (4–11 months) | 12–15 |
| Toddlers (1–2 years) | 11–14 |
| Preschool (3–5 years) | 10–13 |
| School age (6–13 years) | 9–11 |
| Teenagers (14–17 years) | 8–10 |
| Adults (18–64 years) | 7–9 |
| Older adults (65+) | 7–8 |
A landmark 2003 study by Van Dongen et al. (published in Sleep) found that chronic sleep restriction to 6 hours per night for 14 days produced cognitive impairment equivalent to 48 hours of total sleep deprivation — but the subjects did not perceive their impairment. They felt \"fine.\" This disconnect between subjective alertness and objective performance is why sleep debt is dangerous: people with significant debt do not know how impaired they are.
\nShort-term debt (under 20 hours): Yes — with extended sleep over 1–2 weeks. Add 1–2 hours per night until you consistently wake without an alarm. Recovery sleep is most effective when taken soon after the debt is incurred.
\nChronic debt (months or years of under-sleeping): Research is less clear. A 2021 study in Current Biology found that weekend recovery sleep did not fully reverse the metabolic damage of chronic short sleep. The implication: you cannot stockpile sleep, and chronic debt may have partially irreversible health consequences.
\n| System | Effect of chronic sleep debt | Evidence quality |
|---|---|---|
| Cognitive | Reduced attention, memory, and decision quality | Strong (multiple RCTs) |
| Metabolic | Insulin resistance, increased appetite, weight gain | Strong |
| Cardiovascular | Elevated blood pressure, increased heart disease risk | Strong (observational + mechanistic) |
| Immune | Reduced vaccine response, increased infection susceptibility | Moderate |
| Mental health | Increased anxiety, depression risk | Strong (bidirectional relationship) |
Can I function on 6 hours of sleep?
A small percentage of people (estimated <3%) carry a genetic variant (DEC2) that allows them to function normally on 6 hours. For the other 97%, 6 hours produces measurable cognitive impairment that accumulates over days — even if you feel adapted.
Is napping effective for reducing sleep debt?
Short naps (20–30 minutes) improve alertness and performance without causing sleep inertia. They do not fully substitute for lost nighttime sleep but are effective for acute debt. Naps longer than 30 minutes can interfere with nighttime sleep quality.
Should I sleep more on weekends?
If you are sleep-deprived during the week, yes — weekend catch-up is better than nothing. But the optimal strategy is consistent sleep timing 7 days per week. Irregular sleep schedules disrupt circadian rhythm and reduce sleep quality even when total hours are adequate.
A work hours calculator converts start and end times into total hours worked, accounts for breaks, and computes gross pay including overtime. The arithmetic is simple — subtract start from end, deduct breaks — but the rules governing overtime, minimum rest periods, and pay calculation vary by jurisdiction and add real complexity.
\nHours Worked = (End Time − Start Time) − Break Duration
| Example | Start | End | Break | Hours worked |
|---|---|---|---|---|
| Standard day | 9:00 AM | 5:30 PM | 30 min | 8.0 hours |
| Early shift | 6:00 AM | 2:15 PM | 45 min | 7.5 hours |
| Night shift | 10:00 PM | 6:30 AM | 30 min | 8.0 hours |
| Split shift | 8:00 AM | 8:00 PM | 2 hours | 10.0 hours |
| Jurisdiction | Overtime threshold | Overtime rate | Double-time |
|---|---|---|---|
| US (FLSA) | >40 hours/week | 1.5× regular rate | Not federally required |
| California | >8 hours/day OR >40/week | 1.5× | 2× after 12 hours/day |
| UK | No statutory overtime rate | Contractual | Contractual |
| EU (Working Time Directive) | 48-hour weekly maximum | Varies by member state | Varies |
| India | >9 hours/day or >48/week | 2× regular rate | — |
| Australia | Varies by award | 1.5× first 2 hours, 2× after | Yes |
Gross Pay = (Regular Hours × Hourly Rate) + (Overtime Hours × Overtime Rate)
Example: 44 hours worked in a week at $25/hour under FLSA rules. Regular: 40 × $25 = $1,000. Overtime: 4 × $37.50 = $150. Total gross: $1,150.
\nRounding errors: Many employers round to the nearest 15 minutes. Under FLSA rules, rounding must be neutral over time — consistently rounding down is wage theft. The DOL requires that rounding policies do not systematically favour the employer.
\nForgetting unpaid breaks: A 30-minute unpaid lunch means 8.5 hours on-site but only 8 hours paid. The distinction matters for weekly overtime calculations.
\nCross-midnight shifts: A shift from 10 PM to 6 AM spans two calendar days. Hours must be attributed correctly for daily overtime jurisdictions like California.
\nSalaried employees can calculate their effective hourly rate: Annual Salary ÷ 52 weeks ÷ hours per week. A $70,000 salary at 40 hours/week = $33.65/hour. At 50 hours/week (common in salaried roles) = $26.92/hour. The more hours you work beyond 40, the lower your effective hourly rate — a fact that surprises many salaried workers.
\nThe standard US work year is 2,080 hours (40 hours × 52 weeks). After subtracting 10 federal holidays and 15 vacation days, the actual working hours drop to approximately 1,880. For project planning and billing purposes, many organisations use 1,800 billable hours as a realistic annual target.
\nDoes travel time count as work hours?
Under FLSA, normal commuting is not compensable. However, travel during the workday (e.g., driving between client sites) and travel that extends beyond normal working hours (e.g., overnight business trips) may be compensable.
Are on-call hours paid?
It depends on restrictions. If you must stay at or near the workplace, on-call time is generally compensable. If you are free to use the time as you wish (just reachable by phone), it typically is not.
How do I track hours across multiple jobs?
Use separate entries for each employer. For overtime purposes, hours are calculated per employer, not combined — working 30 hours at Job A and 20 hours at Job B does not trigger FLSA overtime at either employer.
Someone aged 35 planning to retire at 60 has 25 years, or 300 months, or about 6,500 remaining working days after weekends and leave. That last figure is the one that tends to focus attention, because it is a number you can actually picture.
But a countdown without a funding figure is just a calendar. The useful question is what those 300 months need to carry.
The most widely used starting estimate says your portfolio should be about 25 times your annual spending. It comes from the 4% withdrawal rule — if you draw 4% of the starting balance each year, adjusted for inflation, a stock-and-bond portfolio historically survived 30 years in the large majority of tested periods.
So a household spending 40,000 a year needs roughly 1,000,000. Note that it is 25 times spending, not income — which is why reducing planned expenses is mathematically identical to saving more, and usually easier. Cutting 5,000 a year from your target lifestyle removes 125,000 from the number you have to accumulate.
The future value of regular contributions, assuming a 7% real return after inflation:
Monthly = target × r ÷ ((1 + r)ⁿ − 1), with r and n in years then divided by 12
| Start age | Years to 60 | Needed per year | Needed per month |
|---|---|---|---|
| 25 | 35 | 7,234 | 603 |
| 35 | 25 | 15,814 | 1,318 |
| 45 | 15 | 39,795 | 3,316 |
| 50 | 10 | 72,378 | 6,032 |
Look at the jump between 35 and 45. Ten years of delay does not raise the cost by 40% — it raises the monthly contribution from 1,318 to 3,316, two and a half times as much, for the identical goal. The reason is that the earliest contributions are the ones with the most years to compound, so they do the heaviest lifting. A payment made at 25 has 35 years of growth behind it; one made at 55 has five.
This is the single most valuable fact in retirement planning, and it is also the least actionable if you are already 45 — in which case the honest levers are a higher saving rate, a later retirement date, or a lower target, and usually some of each.
The rule came from studies of historical US market returns over rolling 30-year periods. Its limitations are well documented and worth knowing before you build a life on it:
This calculation deliberately leaves out several things that will change your actual number: state or employer pensions, which may cover a substantial share of your spending and reduce the portfolio you need; employer matching, which is an immediate return no market can beat; the value of your home, which is not spendable unless you downsize; healthcare costs, which are the largest single uncertainty in many countries; and the possibility of part-time work, which reduces the required multiple sharply in the early years.
A 7% real return is an assumption, not a fact. Long-run global equity returns have been broadly in that region, but with drawdowns of 40% or more along the way and multi-decade periods of lower returns. Nothing here is financial advice, and for a plan involving your actual retirement, a regulated adviser who can see your pensions, tax position and family situation is worth the fee.
Yes, by subtracting it from the spending your portfolio has to cover. If you spend 40,000 and a pension pays 15,000, your portfolio only needs to fund 25,000 — so the target drops from 1,000,000 to 625,000.
Clear the debt first, with one exception: contribute at least enough to capture any employer match, because that is typically an instant 50 to 100% return that no debt rate exceeds.
It assumes you stop drawing a salary. Many people find that earning even a modest amount in the first few retired years dramatically reduces sequence risk, because it avoids selling assets during an early downturn.
No. Everything you enter is used only in your browser and nothing is transmitted or saved.
" }, "life-percentage": { "title": "Life Percentage Calculator — How Much of Your Life Has Passed", "description": "See what share of an expected lifespan you have used, and why the naive subtraction understates how long you are likely to live.", "keywords": "life percentage calculator, percentage of life lived, life expectancy calculator, how much life left, conditional life expectancy", "article": "Enter your date of birth and a life expectancy estimate, and the life percentage calculator returns a single number: how far through your expected lifespan you are, expressed as a percentage. It is a simple division — days lived divided by days expected — but the emotional impact of seeing \"47.3% complete\" tends to be disproportionate to the arithmetic.
\n\nLife Percentage = (Current Date − Birth Date) / (Expected Death Date − Birth Date) × 100
All dates are converted to days for precision. Leap years are accounted for automatically.
\n\n| Region / Country | Male | Female | Overall |
|---|---|---|---|
| Japan | 81.5 | 87.6 | 84.6 |
| Switzerland | 82.0 | 85.9 | 84.0 |
| Australia | 81.3 | 85.4 | 83.3 |
| United Kingdom | 79.4 | 83.0 | 81.2 |
| United States | 74.8 | 80.2 | 77.5 |
| India | 69.4 | 72.0 | 70.8 |
| Nigeria | 53.1 | 55.2 | 54.3 |
| Global average | 70.8 | 75.9 | 73.3 |
These are averages at birth. If you have already reached age 40, your remaining life expectancy is higher than the at-birth average because you have survived the high-mortality early years. Actuarial life tables (published by the Social Security Administration in the US, and ONS in the UK) provide age-adjusted figures.
\n\nPsychologists call it \"mortality salience\" — awareness of one's own finite lifespan. Terror Management Theory (TMT), developed by Greenberg, Pyszczynski, and Solomon, proposes that awareness of death is a fundamental motivator of human behaviour. Making mortality concrete (a percentage rather than an abstract \"someday\") triggers a psychological response that can be either paralysing or motivating, depending on personality and context.
\n\nPriority reassessment: Seeing \"53% complete\" prompts questions like \"Am I spending the remaining 47% on things I actually value?\" Multiple productivity and self-help frameworks (including Tim Urban's \"Life in Weeks\" visualisation) use this effect deliberately.
\nFinancial planning: The percentage maps directly onto retirement planning horizons. At 50% life completion with 0% retirement savings, the maths becomes urgent and specific.
\nHealth motivation: Life expectancy is not fixed. Regular exercise, non-smoking, moderate alcohol, and healthy BMI extend life expectancy by 7–14 years according to a 2018 study in the journal Circulation. That shifts the denominator and the percentage.
\n\n| Factor | Impact on life expectancy |
|---|---|
| Regular exercise (150 min/week) | +3 to 7 years |
| Non-smoking | +8 to 10 years vs. current smoker |
| Healthy BMI (18.5–24.9) | +2 to 5 years |
| Family history of longevity | +3 to 5 years (genetic component 20–30%) |
| Chronic disease (diabetes, heart disease) | −5 to 15 years depending on management |
| Socioeconomic status (top vs. bottom quintile) | +10 to 15 years in the US (Chetty et al., 2016) |
Seneca wrote in On the Shortness of Life: \"It is not that we have a short time to live, but that we waste a great deal of it.\" The life percentage calculator is a quantitative expression of this idea — it does not tell you what to do with the remaining percentage, but it removes the comfortable ambiguity of \"I have plenty of time.\"
\n\nIs life expectancy a reliable predictor of my personal lifespan?
No — it is a population average, not an individual prediction. Your actual lifespan depends on genetics, lifestyle, environment, and chance. The number is useful as a planning horizon, not a forecast.
What life expectancy should I use?
Use your country's current average as a baseline, then adjust upward if you are healthy, active, and non-smoking, or downward if you have significant risk factors. Actuarial tables provide age-adjusted figures that are more accurate than birth-average data.
Should I show this to children?
Exercise judgment. For teenagers studying time management or planning, it can be motivating. For younger children, the mortality framing may be distressing without practical benefit.
Meetings are the largest untracked expense in most companies. A one-hour meeting with eight people at an average loaded cost of $75 per hour costs $600. If that meeting recurs weekly, the annual cost is $31,200 — for a single recurring calendar event. Most organisations run dozens of weekly meetings without ever calculating the total spend.
\n\nMeeting Cost = Σ (Hourly Loaded Cost per Attendee) × Duration in Hours
Loaded cost includes salary, benefits, office space, equipment, and employer taxes. A common multiplier is 1.3–1.5× the gross salary, though the exact figure depends on geography and industry.
\n\n| Role | Base salary | Loaded cost/hour |
|---|---|---|
| Junior engineer | $75,000 | $50 |
| Senior engineer | $140,000 | $92 |
| Product manager | $130,000 | $85 |
| Engineering manager | $170,000 | $112 |
| VP-level executive | $250,000 | $164 |
| C-suite executive | $350,000+ | $230+ |
| Detail | Value |
|---|---|
| Attendees | 8 engineers + 1 PM + 1 EM |
| Average loaded cost | $72/hour |
| Duration | 15 minutes (0.25 hours) |
| Cost per meeting | $180 |
| Annual cost (50 weeks) | $9,000 |
A 15-minute standup seems harmless, but even this small meeting costs $9,000 per year. The question is not whether it is expensive — every meeting with multiple people is expensive — but whether the $9,000 generates more than $9,000 in coordination value. Often it does. The problem is that nobody asks the question.
\n\nMeeting cost calculators typically count only labour time, but research from the University of California, Irvine, shows that it takes an average of 23 minutes to return to full focus after an interruption. A 30-minute meeting in the middle of a coding block effectively costs 53 minutes of productive time per attendee. For deep-work roles like engineering and design, the context-switching cost can exceed the meeting's direct labour cost.
\n\nMicrosoft's 2022 Work Trend Index, based on anonymised data from 31,000 workers, found that the average employee spends 252 percent more time in meetings compared to pre-pandemic levels. The same study found that meeting-heavy weeks correlate with lower self-reported productivity and higher burnout scores. The relationship is not causal — busy periods naturally involve more meetings — but the correlation is strong enough to warrant attention.
\n\nHalve the default duration: Most calendar apps default to 30 or 60 minutes. Changing the default to 25 or 50 minutes builds in transition time and forces tighter agendas.
\nHalve the attendee list: Amazon's \"two-pizza rule\" suggests that no meeting should require more than two pizzas to feed. Smaller meetings make faster decisions and cost less per minute.
\nReplace information meetings with documents: If the meeting is primarily one person presenting while others listen, a written document distributed asynchronously is faster, cheaper, and creates a permanent record.
\n\nHow do I estimate loaded cost without knowing exact benefits?
Multiply the annual base salary by 1.4 and divide by 2,080 (working hours per year). This gives a reasonable estimate for most salaried employees in the US and Europe.
Should I include travel time?
For in-person meetings in different buildings or cities, yes. Travel time is time that could have been spent on productive work, and it should be costed at the same loaded rate.
Is there an optimal meeting length?
Research suggests that meetings over 45 minutes see declining attention and participation. For decision-making meetings, 25 minutes is often sufficient when the pre-read has been circulated.
A salary negotiation calculator takes a current offer and a target salary and shows the compound impact of the difference over 5, 10, and 20 years. The tool exists because human brains systematically undervalue small annual differences. A $5,000 higher starting salary, compounded at 3% annual raises over a 30-year career, is worth $237,000 in cumulative additional earnings — and most people never negotiate at all.
\n\n| Year | Salary at $80,000 start (3% raises) | Salary at $85,000 start (3% raises) | Cumulative gap |
|---|---|---|---|
| 1 | $80,000 | $85,000 | $5,000 |
| 5 | $90,093 | $95,724 | $26,876 |
| 10 | $104,427 | $110,954 | $58,784 |
| 20 | $140,319 | $149,089 | $134,468 |
| 30 | $188,567 | $200,353 | $237,152 |
The gap accelerates because each year's raise is a percentage of the current salary, not the original. This is why negotiating the initial offer — not asking for a raise three years in — has the largest lifetime impact.
\n\nA 2023 Glassdoor survey found that 73% of employers expect candidates to negotiate, yet only 39% of candidates actually do. The primary reasons: fear of the offer being rescinded (which almost never happens for professional roles), discomfort with confrontation, and lack of data about market rates. The negotiation calculator addresses the last problem directly.
\n\n| Component | Negotiable? | Monetary equivalent |
|---|---|---|
| Signing bonus | Almost always | $5,000–$50,000 |
| Equity / stock options | Usually at senior levels | Varies widely; 4-year vest typical |
| Remote work days | Increasingly yes | $5,000–$15,000/year in commuting + time savings |
| Vacation days | Sometimes | 1 day ≈ 0.5% of salary |
| Professional development budget | Usually | $1,000–$5,000/year |
| Title | Often the easiest to negotiate | Indirect — affects future salary anchoring |
The grateful counter: \"Thank you for this offer — I'm excited about the role. Based on my research and the scope of the position, I was expecting something closer to $X. Is there flexibility to close that gap?\" This approach is direct without being aggressive and gives the employer room to respond.
\nThe competing offer: \"I have another offer at $X. I prefer your company for [specific reason], but the compensation difference is significant. Can we discuss bridging it?\" This only works if the competing offer is real — fabricating offers is dishonest and easily caught.
\nThe total compensation reframe: \"If the base salary is firm, could we explore a signing bonus, additional equity, or extra vacation days to bring the total package closer to my target?\" This gives the employer multiple levers and increases the chance of a positive outcome.
\n\nBefore negotiating, establish a defensible market range using at least three data sources: Levels.fyi (tech-focused, includes equity), Glassdoor (broad, self-reported), the Bureau of Labor Statistics Occupational Outlook Handbook (government data, lags 1–2 years), PayScale (adjusted for geography and experience), and LinkedIn Salary (requires profile data). The intersection of three or more sources gives a credible range.
\n\nResearch consistently shows that women negotiate less frequently and receive smaller increases when they do. A 2023 meta-analysis in the Journal of Applied Psychology found that men initiate negotiations 1.5× more often and secure 7.4% higher first offers on average. The gap is driven by social expectations, backlash risk, and information asymmetry — all of which structured negotiation tools can help reduce.
\n\nCan negotiating cost me the offer?
In professional and corporate hiring, almost never. A 2019 survey by Robert Half found that only 1% of hiring managers withdrew offers after a candidate negotiated. The risk is overwhelmingly lower than the reward.
When should I NOT negotiate?
Government jobs with fixed pay scales, union positions with collective agreements, and roles where the offer explicitly states \"non-negotiable\" (rare). Even in these cases, benefits and start date are often flexible.
How much above the offer should I counter?
10–20% above the initial offer is the standard range. Going higher requires strong justification (unique skills, competing offers, market data). Going lower than 10% is usually not worth the negotiation effort.
Most freelancers set rates by guessing, copying competitors, or converting their last salary to hourly. All three methods are unreliable. A proper rate calculation works backwards from your financial needs, accounts for the hidden costs of self-employment, and produces a number you can defend in negotiation.
\n\nHourly Rate = (Annual Expenses + Profit Margin) / Billable Hours Per Year
Each variable hides complexity that most rate calculators gloss over.
\n\n| Category | Employee (covered by employer) | Freelancer (self-funded) |
|---|---|---|
| Health insurance | Employer pays 70–80% | 100% self-funded ($6,000–$15,000/year in the US) |
| Retirement contributions | Employer match (3–6%) | Self-funded (target 15–20% of income) |
| Payroll taxes (employer portion) | Employer pays 7.65% FICA | Self-employment tax: 15.3% on net earnings |
| Paid time off | 10–20 days paid | $0 income during time off |
| Equipment and software | Company-provided | $2,000–$5,000/year |
| Accounting and legal | HR department | $1,000–$3,000/year |
A common rule of thumb: freelancers need to earn 1.4–1.6 times their equivalent salary to match the same take-home pay and benefits. A $80,000 salaried position requires freelance revenue of $112,000–$128,000.
\n\nThe single biggest mistake freelancers make is dividing by 2,080 (40 hours × 52 weeks). In practice, only 60–70 percent of work hours are billable. The rest goes to:
\nRealistic billable hours for a full-time freelancer: 1,000–1,400 per year, not 2,080.
\n\n| Line item | Amount |
|---|---|
| Desired take-home salary | $80,000 |
| Self-employment tax (15.3%) | $12,240 |
| Health insurance | $8,400 |
| Retirement savings (15%) | $12,000 |
| Equipment, software, subscriptions | $3,600 |
| Accounting and legal | $2,000 |
| Profit margin (10%) | $11,824 |
| Total annual revenue needed | $130,064 |
| Billable hours (1,200/year) | — |
| Hourly rate | $108 |
This is the minimum sustainable rate, not the aspirational one. Charging $50/hour with these numbers means working 2,600 billable hours per year — which is physically impossible without burnout.
\n\nHourly billing is transparent but penalises efficiency: as you get faster, you earn less per project. Project-based pricing rewards expertise and aligns incentives with the client's outcomes. Most experienced freelancers transition to project pricing over time, using their hourly rate internally to scope and quote projects.
\n\nThree reliable signals: you are booked more than 80 percent of the time for three consecutive months; new clients accept your rate without negotiation; or you have developed specialist expertise that fewer competitors offer. Raise by 10–20 percent for new clients and grandfather existing clients for one billing cycle.
\n\nShould I charge less when starting out?
Slightly lower rates are reasonable for the first 3–6 months while building a portfolio, but never below your cost floor. Underpricing attracts price-sensitive clients who are the hardest to work with and the most likely to dispute invoices.
How do I handle clients who say my rate is too high?
Reframe the conversation around value delivered, not hours spent. If a $5,000 project saves the client $50,000, the rate is irrelevant. If the client still pushes back, they may not be the right fit.
Do rates vary by country?
Significantly. A senior developer in the US charges $100–$200/hour; the same skill set in South Asia might bill $25–$50/hour. Geographic arbitrage is real, but so are cost-of-living differences that drive those rates.
A savings goal calculator takes four inputs — target amount, time horizon, current savings, and expected return — and tells you how much to set aside each month. The arithmetic is straightforward compound-interest algebra, but the result is only as honest as the assumptions, and the default assumptions on most calculator sites are quietly optimistic.
\n\nIf you need a future value FV, already have a present value PV, earn a monthly rate r, and have n months, the required monthly contribution C is:
\nC = (FV − PV × (1+r)^n) / ((1+r)^n − 1) × r
This is the standard annuity formula rearranged to solve for payment. Every savings calculator on the internet uses it; the differences are in what they assume for r and whether they adjust for inflation.
\n\n| Asset class | Nominal long-run return (annualised) | After 3% inflation |
|---|---|---|
| High-yield savings account | 4.5–5.0% | 1.5–2.0% |
| Government bonds (10-year) | 4.0–5.0% | 1.0–2.0% |
| Diversified equity index (S&P 500) | 9.5–10.5% | 6.5–7.5% |
| Balanced 60/40 portfolio | 7.0–8.0% | 4.0–5.0% |
Most calculator defaults use 6–8 percent without specifying whether that is real or nominal. If you are saving for a goal ten years away, a 3 percent annual inflation difference compounds into a 34 percent gap in purchasing power. Always use the real (inflation-adjusted) return, or inflate your target by the expected CPI rate.
\n\nCompound interest is not linear. A single $5,000 deposit at the start of a 20-year plan at 6 percent real grows to $16,036. The same $5,000 deposited 10 years in grows to only $8,954. Timing the lump sum matters almost as much as the amount, which is why financial planners emphasise starting early over starting large.
\n\n| Return assumption | Monthly contribution needed | Total paid in | Interest earned |
|---|---|---|---|
| 0% (mattress savings) | $833 | $100,000 | $0 |
| 3% real | $715 | $85,800 | $14,200 |
| 6% real | $610 | $73,200 | $26,800 |
| 8% real | $547 | $65,640 | $34,360 |
The gap between 0 percent and 6 percent is $223 per month — meaningful, but not transformative for most budgets. The real lesson is that even modest returns dramatically reduce the total out-of-pocket cost over a decade.
\n\nIgnoring taxes on returns: Interest, dividends, and capital gains are taxed in most jurisdictions. A 6 percent return in a taxable account at a 25 percent marginal rate is effectively 4.5 percent. Use tax-advantaged accounts (ISA, 401(k), RRSP, PPF) wherever possible.
\nSetting one large goal instead of milestones: A $100,000 target over 10 years feels abstract. Break it into annual checkpoints: $8,500 after year one, $18,000 after year two, and so on. Each checkpoint gives you a feedback loop and a reason to celebrate or course-correct.
\nNot accounting for income growth: Most people's income rises over time. A flat monthly contribution ignores the fact that $700 per month is harder to sustain at age 22 than at age 30. Consider starting with a lower contribution and increasing it by 3–5 percent annually — many employers automate this in retirement plans.
\n\nBehavioural economists have consistently found that people save more when the goal is concrete and visual. A 2019 study in the Journal of Consumer Research found that savers who named their accounts after specific goals (e.g., \"Tokyo Trip 2027\") saved 27 percent more than those using generic labels (\"Savings\"). The Gen Code Tools savings goal calculator lets you name your target for this reason.
\n\nShould I include employer match in my savings calculation?
Yes — an employer match is free money and should be included in the \"current savings\" or \"additional contributions\" field. Not including it understates your progress.
How often should I recalculate?
Annually, or whenever your income, expenses, or market conditions change significantly. A savings plan is a living document, not a one-time calculation.
What if I miss a month?
One missed month over a 10-year plan has negligible impact — about 0.1 percent of the final balance. Three consecutive missed months is more serious and suggests the contribution level needs adjustment.
Every purchase has two prices: the number on the tag and the real cost per time you use the item. A $200 jacket worn 150 times costs $1.33 per use. A $50 jacket worn 5 times costs $10 per use. The cheap jacket is the expensive one — and most buying decisions get this wrong because human brains anchor on sticker price, not usage rate.
\n\nCost per use is deceptively simple:
\nCost Per Use = (Purchase Price − Resale Value) / Number of Uses
Including resale value matters for items with active secondary markets — electronics, designer goods, vehicles. A $1,000 phone sold for $400 after two years and used daily has a cost per use of ($1,000 − $400) / 730 = $0.82.
\n\n| Item | Purchase price | Expected uses | Cost per use | Verdict |
|---|---|---|---|---|
| Daily-wear shoes | $180 | 300 | $0.60 | Excellent |
| Gym membership (annual) | $600 | 156 (3x/week) | $3.85 | Good |
| Gym membership (annual) | $600 | 24 (2x/month) | $25.00 | Poor |
| Stand mixer | $350 | 50 (over 10 years) | $7.00 | Moderate |
| Fast-fashion dress | $30 | 3 | $10.00 | Poor |
| Quality wool coat | $400 | 500 (over 8 winters) | $0.80 | Excellent |
Behavioural economists identify three biases that distort purchase decisions against cost-per-use thinking:
\nAnchoring on sticker price: The $400 coat triggers loss aversion even when the $30 dress is objectively more expensive per wear. We anchor on the immediate cash outflow, not the amortised cost.
\nOptimism bias on usage: People consistently overestimate how often they will use new purchases. The treadmill, the bread maker, the language course — each is bought with the best of intentions and realistic usage rates that are two to five times too high.
\nSunk cost neglect: Once a purchase is made, people stop tracking whether they use it enough to justify the cost. The gym membership is a classic: the pain of cancelling feels like admitting failure, so the $25-per-visit membership continues month after month.
\n\nClothing: The fashion industry depends on low sticker prices and high replacement rates. Applying cost-per-use thinking to a wardrobe typically reduces total spending while increasing the quality of what you own. A useful rule: if you would not wear it at least 30 times, the cost per use is probably too high.
\nTechnology: Phones, laptops, and tablets have a clear expected lifespan. Buying a $1,500 laptop that lasts 5 years ($0.82/day) is almost always cheaper than buying a $600 laptop that lasts 2 years ($0.82/day) — but the higher-spec machine typically lasts longer, making the real comparison favour the premium device.
\nSubscriptions: Every subscription is a recurring cost-per-use calculation. A $15/month streaming service used 20 times a month is $0.75 per use. Used twice a month, it is $7.50 — at which point renting individual titles is cheaper.
\n\nThe environmental case for cost-per-use thinking is strong. The Ellen MacArthur Foundation estimates that extending the average lifespan of clothing by just nine months would reduce carbon, water, and waste footprints by 20–30 percent. Buying fewer, better items and using them more is both the cheapest and the greenest strategy.
\n\nWhat is a good cost per use?
It depends on the category. For clothing, under $1 is excellent. For electronics, under $1 per day is solid. For subscriptions, compare the per-use cost to the single-purchase alternative.
Should I include maintenance costs?
Yes. A $180 pair of shoes that needs $30 in resoling has a true cost of $210 over 300 uses — still $0.70 per use, which is excellent.
Does cost per use apply to experiences?
Partially. A concert ticket or a vacation has exactly one use, so cost per use equals the ticket price. The metric is most useful for items you use repeatedly.
The email tone analyser evaluates the emotional register of your email text — is it formal, casual, assertive, passive, friendly, or terse? — by examining word choice, sentence length, punctuation patterns, and hedging language. Tone is the dimension of communication that email strips out by removing facial expressions, vocal inflection, and body language. Getting it wrong costs relationships, deals, and promotions.
\nThe analyser scores text across multiple dimensions using Natural Language Processing (NLP) heuristics:
\n| Dimension | Positive indicators | Negative indicators |
|---|---|---|
| Warmth | First names, \"thank you,\" collaborative language (\"we,\" \"together\") | No greeting, no sign-off, impersonal language |
| Confidence | Direct statements, active voice, clear requests | Hedging words (\"just,\" \"maybe,\" \"sort of\"), excessive qualifiers |
| Formality | Full sentences, proper punctuation, professional vocabulary | Slang, emoji, sentence fragments |
| Urgency | \"By Friday,\" \"time-sensitive,\" specific deadlines | No timeline, vague requests (\"when you get a chance\") |
| Negativity | — | \"Unfortunately,\" \"disappointed,\" \"unacceptable,\" \"concerned\" |
\"Just\" and \"sorry\" overuse: \"I just wanted to check in\" and \"Sorry to bother you\" undermine the sender's authority. Research by Ellen Leanse (former Google executive) found that women use \"just\" in professional emails 2.5× more often than men. Removing it almost always makes the message stronger.
\nMissing warmth in bad-news emails: \"Your request has been denied\" lands differently than \"I understand why this matters to your team. Unfortunately, the budget for this quarter is committed, and I'm unable to approve this request. Let's discuss alternative timing for Q2.\" Same outcome, dramatically different emotional impact.
\nPassive aggression through punctuation: \"Per my last email.\" \"As previously stated.\" \"Please advise.\" These phrases are technically neutral but have become culturally loaded as passive-aggressive signals. The analyser flags them because they consistently produce negative reader reactions.
\n| Context | Ideal tone | Avoid |
|---|---|---|
| Client proposal | Confident, professional, warm | Hedging, uncertainty, informality |
| Team update | Direct, collaborative, concise | Formality that creates distance |
| Performance feedback | Specific, constructive, empathetic | Vagueness, accusatory language |
| Cold outreach | Personal, specific, brief | Generic templates, hard sells |
| Apology | Accountable, specific, solution-oriented | Deflection (\"mistakes were made\"), over-apologising |
Email tone norms vary significantly across cultures. American business email tends toward warmth and informality (\"Hey Sarah, hope you're doing well!\"). German business email is more formal and direct (\"Sehr geehrte Frau Schmidt\"). Japanese business email follows strict hierarchical politeness levels (keigo). An email that reads as friendly in New York may read as unprofessional in Frankfurt or overly casual in Tokyo.
\nA 2005 study by Justin Kruger (NYU) found that people overestimate their ability to communicate tone via email by about 50%. Senders believed their sarcasm, humour, or seriousness was obvious; recipients interpreted it correctly only about half the time. The conclusion: when tone matters, over-communicate it. State your intent explicitly rather than relying on the reader to infer it from word choice alone.
\nShould business emails include emoji?
Context-dependent. Within a team that uses them regularly, a 😊 conveys warmth. In a first email to a senior executive, it reads as unprofessional. When in doubt, leave them out.
How long should a professional email be?
Boomerang's analysis of 40 million emails found that messages between 50 and 125 words have the highest response rates. Above 200 words, response rates drop sharply.
Does the analyser replace human judgment?
No. It flags patterns associated with common tone issues — hedging, negativity, formality mismatches. The final decision on tone always requires understanding the specific relationship and context.
A palindrome reads the same forwards and backwards. \"racecar\" is one; \"hello\" is not. The concept is older than computing — the earliest known palindrome is the Latin Sator Arepo square from Pompeii, carved before 79 AD — but the algorithmic check is a foundation of computer science education and interview screening.
\n\nThe most common approach uses two pointers, one at each end of the string, moving inward:
\n| Step | Left pointer | Right pointer | Match? |
|---|---|---|---|
| 1 | r (index 0) | r (index 6) | Yes |
| 2 | a (index 1) | a (index 5) | Yes |
| 3 | c (index 2) | c (index 4) | Yes |
| 4 | e (index 3) — middle | — | Done |
Time complexity is O(n/2), which simplifies to O(n). Space complexity is O(1) because no additional data structure is needed — you compare characters in place. This makes the two-pointer method strictly better than reversing the string and comparing, which uses O(n) extra space.
\n\nCase sensitivity: \"Racecar\" is a palindrome to a human reader but not to a naïve algorithm that compares ASCII values. Normalise to lowercase before checking.
\nSpaces and punctuation: \"A man, a plan, a canal: Panama\" is the most famous sentence-level palindrome, but only if you strip non-alphanumeric characters first. The question of what counts as a character is surprisingly important in multilingual contexts.
\nUnicode and emoji: JavaScript's string indexing treats surrogate pairs (emoji, many CJK characters) as two indices. A proper palindrome checker must iterate by code point, not by UTF-16 code unit. This is a common source of bugs in production code.
\nSingle character and empty string: Both are palindromes by definition. An empty string reads the same forwards and backwards (vacuously true), and a single character trivially satisfies the condition.
\n\nNumbers can be palindromic too: 121, 1331, 12321. Numeric palindromes appear in Project Euler problems, competitive programming, and recreational mathematics. The Lychrel conjecture asks whether every natural number eventually becomes a palindrome when you repeatedly reverse and add — 196 has been tested to billions of digits without producing one, but no proof exists either way.
\n| Starting number | Steps to palindrome | Result |
|---|---|---|
| 56 | 1 | 56 + 65 = 121 |
| 78 | 4 | 78 → 165 → 726 → 1353 → 4884 |
| 89 | 24 | 8,813,200,023,188 |
| 196 | Unknown | No palindrome found after billions of iterations |
Molecular biologists use \"palindrome\" differently: a DNA palindrome is a sequence where the complementary strand reads the same in the opposite direction. The restriction enzyme EcoRI recognises the palindromic sequence GAATTC (complement: CTTAAG, reversed: GAATTC). These biological palindromes are critical to gene editing, CRISPR targeting, and forensic DNA analysis.
\n\nPalindrome problems are among the most common in coding interviews because they test string manipulation, edge-case handling, and algorithmic thinking in a compact problem. Variants include: longest palindromic substring (Manacher's algorithm, O(n)), palindrome partitioning (dynamic programming), and checking if a string can become a palindrome with at most one deletion.
\n\nIs \"Was it a car or a cat I saw?\" a palindrome?
Yes — after removing spaces and punctuation and lowering case, it reads \"wasitacaroracatisaw\", which is identical reversed.
What is the longest known palindrome word?
In English, \"tattarrattat\" (coined by James Joyce in Ulysses to imitate a knock on a door) is often cited. In Finnish, \"saippuakivikauppias\" (a soapstone seller) is a naturally occurring 19-letter palindrome.
Can numbers be checked the same way?
Yes. Convert the number to a string and apply the same two-pointer algorithm, or work with digits directly using modular arithmetic.
Sorting lines of text seems trivial until you encounter locale-sensitive strings, mixed-case entries, numeric prefixes, or trailing whitespace. The right sort order depends on what you are sorting and why — and choosing wrong can produce results that look correct in English but break in German, Japanese, or Arabic.
\n\nMost text sorters — including this tool — use a comparison-based sort. The underlying algorithm is typically Timsort (used by Python and JavaScript's V8 engine), which combines merge sort and insertion sort for an average and worst-case time complexity of O(n log n). The critical variable is not the algorithm but the comparison function.
\n\n| Sort mode | What it compares | Example order |
|---|---|---|
| Lexicographic (ASCII) | Raw byte values | Apple, Banana, apple (uppercase before lowercase) |
| Case-insensitive | Lowered strings | apple, Apple, Banana |
| Natural / human sort | Numeric segments by value | file1, file2, file10 (not file1, file10, file2) |
| Locale-aware (Intl.Collator) | Language-specific rules | ä sorts after a in German (DIN 5007-1), but as ae in phonebooks (DIN 5007-2) |
| Reverse | Any of the above, reversed | Banana, apple, Apple |
| Random shuffle | Random comparator | Unpredictable each time |
Default lexicographic sort treats \"file10\" as less than \"file2\" because the character \"1\" (ASCII 49) comes before \"2\" (ASCII 50). Natural sort extracts numeric segments and compares them as numbers, producing the order humans expect: file1, file2, file10, file20, file100. Windows Explorer, macOS Finder, and most file managers use natural sort for filenames.
\n\nIn Swedish, \"ö\" sorts after \"z\". In German, \"ö\" sorts with \"o\". In Turkish, dotless \"ı\" and dotted \"İ\" are distinct letters, and case conversion rules differ from English (lowercase \"I\" is \"ı\", not \"i\"). A text sorter that ignores locale will produce wrong results for any non-ASCII language. JavaScript's Intl.Collator handles this correctly when given the right locale tag.
A common use case is sorting and then removing duplicate lines — the Unix sort -u pattern. This is useful for cleaning email lists, merging log files, and preparing data for diff comparison. The Gen Code Tools line sorter includes a \"remove duplicates\" option that performs both operations in a single pass.
| Lines | Expected sort time (browser, Timsort) |
|---|---|
| 1,000 | <1 ms |
| 10,000 | ~5 ms |
| 100,000 | ~80 ms |
| 1,000,000 | ~900 ms |
For files over 100,000 lines, the browser tab may briefly freeze. The tool uses a Web Worker for large inputs to avoid blocking the UI thread.
\n\nCSV column extraction: Copy one column from a spreadsheet, paste into the sorter, sort alphabetically, and remove duplicates to get a clean unique-values list. Faster than writing a formula or opening a database tool.
\nMerge conflict resolution: When two developers add entries to the same list in different orders, sorting both lists and comparing makes the diff trivial.
\nSEO keyword lists: Sort keyword research exports alphabetically to group related terms and spot duplicates that inflated the count.
\n\nDoes the sorter handle tabs and mixed whitespace?
Yes. Each line is trimmed of leading/trailing whitespace before comparison. Interior whitespace is preserved in the output.
Can I sort by a specific column?
The line sorter sorts by the entire line. For column-specific sorting, use a CSV-aware tool or spreadsheet.
Is there a line limit?
No hard limit, but performance degrades above 500,000 lines in a browser. For truly massive files, use a command-line tool like GNU sort.
The steps-to-calories conversion depends on three variables: your weight, your stride length, and your walking speed. A commonly cited figure — 100 calories per mile, or about 2,000 steps — is a rough average for a 155-pound person on flat ground. The actual number varies by 40–60% depending on individual factors.
\nCalories = Steps × Stride Length (m) / 1000 × MET × Weight (kg) / Speed (km/h)
A simpler approximation: Calories ≈ Steps × 0.04 × (Weight in kg / 70). This assumes an average stride and moderate pace.
| Steps | 60 kg (132 lbs) | 70 kg (154 lbs) | 80 kg (176 lbs) | 90 kg (198 lbs) |
|---|---|---|---|---|
| 2,000 | 56 cal | 66 cal | 75 cal | 84 cal |
| 5,000 | 140 cal | 164 cal | 187 cal | 210 cal |
| 7,500 | 210 cal | 245 cal | 280 cal | 315 cal |
| 10,000 | 280 cal | 327 cal | 374 cal | 420 cal |
| 15,000 | 420 cal | 491 cal | 561 cal | 631 cal |
The 10,000-step goal originated from a 1965 Japanese marketing campaign for the Manpo-kei pedometer (万歩計 literally means \"10,000-step meter\"). It was not based on clinical research. However, subsequent studies have broadly supported 7,000–10,000 steps as a beneficial daily range. A 2020 JAMA study of 4,840 adults found that participants who walked 8,000+ steps per day had a 51% lower mortality risk than those walking 4,000 steps — but the incremental benefit plateaued above 12,000 steps.
\n| Height | Estimated stride (walking) | Estimated stride (running) |
|---|---|---|
| 5'0\" (152 cm) | 58 cm | 90 cm |
| 5'6\" (168 cm) | 66 cm | 102 cm |
| 5'10\" (178 cm) | 71 cm | 110 cm |
| 6'2\" (188 cm) | 76 cm | 118 cm |
These are estimates. To measure your actual stride: walk 10 steps on a flat surface, measure the total distance, and divide by 10. Use the measured value for more accurate calorie calculations.
\nFaster walking burns more calories per step because the biomechanical effort increases non-linearly. At 2 mph (slow stroll), the MET value is 2.0. At 3.5 mph (brisk walk), the MET rises to 3.5 — a 75% increase in energy expenditure per unit of time. This is why health guidelines specify \"brisk\" walking, not just any walking.
\n| Metric | Strength | Weakness |
|---|---|---|
| Steps | Easy to measure; motivating; correlates with general activity | Ignores intensity, elevation, and non-walking activity |
| Active minutes | Captures intensity; aligns with WHO guidelines (150 min/week) | Doesn't distinguish walking from vigorous exercise |
| Heart rate zones | Directly measures cardiovascular effort | Requires a sensor; affected by caffeine, stress, medication |
| Calories burned | Universal energy metric | Estimated with 15–27% error (Stanford, 2017) |
Do steps on a treadmill count the same as outdoor steps?
Approximately — but outdoor walking on uneven terrain burns 5–10% more calories due to balance adjustments and wind resistance. Incline settings on a treadmill partially compensate.
Do running steps burn more than walking steps?
Per step, running burns slightly more because the vertical displacement is greater. Per mile, running and walking burn similar total calories (about 80–100 kcal per mile), but running covers the mile faster.
Should I trust my phone's step count?
Modern smartphones are reasonably accurate for walking (±5%) but overcount during driving (vibrations register as steps) and undercount when the phone is in a bag rather than a pocket. Dedicated pedometers and fitness bands are more consistent.
An intermittent fasting timer tracks your eating and fasting windows and tells you how far through your current fast you are. The tool is simple; the science behind fasting is not. Claims range from credible (improved insulin sensitivity) to exaggerated (reversal of ageing), and understanding which is which requires looking at the actual research.
\n| Protocol | Fasting window | Eating window | Frequency |
|---|---|---|---|
| 16:8 (Leangains) | 16 hours | 8 hours | Daily |
| 18:6 | 18 hours | 6 hours | Daily |
| 20:4 (Warrior Diet) | 20 hours | 4 hours | Daily |
| 5:2 | 2 days at 500–600 cal | 5 days normal eating | Weekly |
| OMAD (One Meal a Day) | ~23 hours | ~1 hour | Daily |
| Alternate Day Fasting | 36 hours | 12 hours | Every other day |
| Hours fasted | Metabolic event |
|---|---|
| 0–4 | Fed state. Insulin elevated, glucose being used as primary fuel. |
| 4–8 | Early post-absorptive state. Blood glucose falling, insulin declining. |
| 8–12 | Glycogen depletion begins. Liver glycogen stores are drawn down. |
| 12–18 | Fat oxidation increases significantly. Ketone production begins. |
| 18–24 | Autophagy upregulated (cellular cleanup process). Growth hormone rises. |
| 24–48 | Deep ketosis. Autophagy peaks. Not recommended without medical guidance. |
Weight loss: Multiple randomised controlled trials show that intermittent fasting produces weight loss comparable to continuous caloric restriction — not superior. A 2020 meta-analysis in the Annual Review of Nutrition found that the primary mechanism is reduced total caloric intake, not metabolic magic. Fasting is an eating pattern that helps some people eat less, not a metabolic hack.
\nInsulin sensitivity: Time-restricted eating (especially early time-restricted eating, where the eating window ends by mid-afternoon) has shown improvements in insulin sensitivity and fasting glucose in several studies. A 2022 NEJM review noted that these benefits are most consistent in adults with prediabetes or metabolic syndrome.
\nAutophagy: Autophagy — the process by which cells break down and recycle damaged components — is upregulated during fasting. However, measuring autophagy in living humans is technically difficult, and most autophagy research is based on animal models or cell cultures. The popular claim that \"autophagy starts at 16 hours\" is an oversimplification of complex, continuous cellular processes.
\nPregnant or breastfeeding women, individuals with a history of eating disorders, people with Type 1 diabetes, children and adolescents, and anyone taking medication that requires food. Fasting is a nutritional strategy, not a universal prescription, and it should be discussed with a healthcare provider for anyone in these groups.
\nDoes coffee break a fast?
Black coffee (no sugar, no cream) does not meaningfully affect insulin or caloric intake and is generally considered fast-safe. Adding milk or sweetener technically breaks the fast.
Can I exercise while fasting?
Light to moderate exercise is fine for most people. High-intensity or strength training may benefit from post-workout nutrition, so schedule heavy workouts near the eating window.
Is fasting better than just eating less?
For weight loss, they are equivalent in clinical trials. Fasting may offer additional metabolic benefits (improved circadian rhythm, insulin sensitivity) that continuous restriction does not, but the evidence is still emerging.
A decision matrix — also called a weighted scoring model, Pugh matrix, or criteria-based decision analysis — replaces gut feeling with structured comparison. You list your options as rows, your criteria as columns, score each option against each criterion, and multiply by weights. The option with the highest total score wins. The method does not make the decision for you; it makes your reasoning visible and challengeable.
\n\nUse a matrix when you have three or more options, three or more criteria that matter, and the stakes are high enough to warrant 15 minutes of structured thinking. Common applications include job offer comparison, vendor selection, technology stack evaluation, city relocation, and product feature prioritisation.
\n\n| Step | Action | Example (choosing a laptop) |
|---|---|---|
| 1 | List options | MacBook Air M3, ThinkPad X1, Dell XPS 15 |
| 2 | List criteria | Battery life, weight, screen quality, price, keyboard |
| 3 | Assign weights (must total 100%) | Battery 25%, Weight 20%, Screen 20%, Price 20%, Keyboard 15% |
| 4 | Score each option per criterion (1–10) | See matrix below |
| 5 | Multiply scores by weights and sum | See totals below |
| Criterion | Weight | MacBook Air | ThinkPad X1 | Dell XPS 15 |
|---|---|---|---|---|
| Battery life | 25% | 9 (2.25) | 7 (1.75) | 6 (1.50) |
| Weight | 20% | 9 (1.80) | 8 (1.60) | 6 (1.20) |
| Screen quality | 20% | 8 (1.60) | 8 (1.60) | 9 (1.80) |
| Price | 20% | 6 (1.20) | 5 (1.00) | 7 (1.40) |
| Keyboard | 15% | 7 (1.05) | 9 (1.35) | 7 (1.05) |
| Total | 7.90 | 7.30 | 6.95 |
The MacBook Air scores highest, driven by its battery and weight advantages. But notice that the ThinkPad wins on keyboard quality — if you adjusted the keyboard weight from 15% to 30%, the outcome would change. This sensitivity is a feature, not a bug: the matrix makes your priorities explicit and testable.
\n\nToo many criteria: More than 7 criteria dilute the weights so much that every option scores similarly. Limit criteria to the 5–7 factors that actually differentiate the options.
\nAnchoring on the first score: Once you score Option A as 8/10 on price, you unconsciously calibrate all other price scores relative to it. Score all options on one criterion at a time, moving across the row, not down the column.
\nIgnoring dealbreakers: A decision matrix is a compensatory model — a high score on one criterion can compensate for a low score on another. If any criterion is a hard requirement (e.g., \"must weigh under 3 lbs\"), filter out disqualified options before building the matrix.
\n\nPugh Matrix: Uses a baseline option (the current choice or market leader) and scores others as better (+1), same (0), or worse (−1) relative to the baseline. Faster than absolute scoring and useful for early-stage screening.
\nAHP (Analytic Hierarchy Process): Uses pairwise comparison of criteria to derive mathematically consistent weights. More rigorous than subjective weight assignment but significantly more time-consuming.
\n\nHow do I assign weights objectively?
Start by ranking criteria from most to least important, then distribute 100 points across them. If two criteria feel equally important, give them equal points. The ranking forces trade-offs that direct assignment often avoids.
What scoring scale should I use?
1–5 is too coarse for more than 3 options; 1–10 provides enough resolution for most decisions. Some practitioners use 1–100, but the additional precision is usually false precision.
Can I use a decision matrix for group decisions?
Yes — have each participant score independently, then average the scores. Discuss the largest disagreements, as they reveal different assumptions or values that should be resolved before choosing.
It sounds like an abdication. It is not, for a specific and narrow class of decisions: the ones where the options are close in value and the deliberation costs more than the difference between them.
If two restaurants are roughly equally good, twenty minutes of discussion is a pure loss. If two features are both defensible, a week of debate costs more than picking the slightly worse one and shipping. The philosophical version is Buridan ass — an animal placed exactly between two identical bales of hay starves while deciding. The practical version is a coin.
There is also a genuinely interesting empirical finding here. An economist ran a large experiment in which people facing real dilemmas — quit the job, end the relationship, move city — were assigned an outcome by coin flip. Among those who followed it, the ones who made the change reported higher happiness six months later than those who stayed. The interpretation the author offered is that people are systematically biased toward the status quo, so when a decision is genuinely marginal, the change is more often the better bet than we feel it is. That is one study on a self-selected sample, so hold it loosely — but it suggests that if you are agonising, inertia is not the neutral option it appears to be.
Anything irreversible, anything high-stakes, anything where you have not actually gathered the available information, and anything where the options are not close. Randomising a medical decision, a large financial commitment or a hire is not decisiveness. And critically: a random pick does not legitimise a bad list. If every option is poor, the tool returns a poor option with a clean conscience attached.
A useful test before using it: if the coin gives you the answer you did not want and you feel relief rather than resistance, the decision was genuinely marginal. If you immediately want to flip again, it was not marginal at all — you already knew, and what you wanted was permission.
Two technical issues determine whether a picker is genuinely unbiased.
The source. The standard Math.random in browsers is a pseudo-random generator: fast, statistically fine for choosing lunch, but deterministic and not suitable where an adversary might predict it. For anything where fairness must be defensible — a prize draw, a raffle — a cryptographic source such as crypto.getRandomValues is the correct choice.
Modulo bias. This is the subtle one. To pick from 6 options, code often takes a large random integer and applies the remainder operator. But if the generator range is not an exact multiple of 6, the low-numbered outcomes occur slightly more often than the high ones, because the leftover partial block at the top of the range only covers some of the options.
With a 32-bit range and 6 options the bias is around one part in 700 million — utterly irrelevant for a dice roll. With a small range or many options it becomes measurable. The proper fix is rejection sampling: discard any value that falls in the incomplete final block and draw again. It costs an occasional extra draw and produces a perfectly uniform result.
Sometimes you want unequal odds — a 3 in 10 chance for one option. The standard technique sums the weights, draws a number in that total range, then walks the list subtracting weights until the remainder goes negative:
| Option | Weight | Cumulative | Range |
|---|---|---|---|
| A | 5 | 5 | 0 – 4.99 |
| B | 3 | 8 | 5 – 7.99 |
| C | 2 | 10 | 8 – 9.99 |
A draw of 6.4 lands in B range. Weights do not need to sum to any particular number, since they are normalised by the total.
Randomness has no memory. Five heads in a row does not make tails more likely on the sixth — that is the gambler fallacy, and it is the single most persistent misunderstanding about random processes. A fair picker will produce runs and clusters that feel wrong; genuinely random sequences look far lumpier than people expect, which is why deliberately spread-out sequences feel more random and are not.
Also, small samples say nothing. Picking the same name three times from a list of five is entirely unremarkable — the probability is 1 in 25 for any specific name, and something surprising happens most of the time.
You can, but then you are not using a random picker — you are using it as a prompt to notice your preference, which is a legitimate but different tool. Decide in advance whether the result binds you.
Not meaningfully, and physical coins have small measurable biases from their weight distribution and the spin imparted. A cryptographic generator is more uniform than any coin.
Shuffle the whole list with a Fisher-Yates shuffle and take the first n. Repeatedly drawing and rejecting duplicates works but gets slow as the list empties.
No. The list you enter is used only in your browser and nothing is transmitted or saved.
" }, "priority-matrix": { "title": "Priority Matrix — Urgent Against Important, Used Properly", "description": "Sort tasks into the four urgency and importance quadrants, see where time actually goes against where it should, and understand what the matrix cannot resolve.", "keywords": "priority matrix, eisenhower matrix, urgent important matrix, quadrant 2 time management, task prioritisation, do schedule delegate delete", "article": "A priority matrix is a visual framework for deciding what to work on first. The basic idea is universal: plot tasks on two axes, then work the quadrant that produces the most value. But different frameworks use different axes, and choosing the wrong framework for your context produces misleading priorities.
\n| Urgent | Not Urgent | |
|---|---|---|
| Important | Do immediately | Schedule deliberately |
| Not Important | Delegate | Eliminate |
Popularised by Stephen Covey in The 7 Habits of Highly Effective People (attributed to President Eisenhower), this matrix separates urgency from importance. The key insight: most people spend too much time in the \"urgent but not important\" quadrant (reactive email, unnecessary meetings) and too little in the \"important but not urgent\" quadrant (strategic planning, relationship building, skill development). The matrix makes this imbalance visible.
\n| Low Effort | High Effort | |
|---|---|---|
| High Impact | Quick wins — do first | Major projects — plan carefully |
| Low Impact | Fill-ins — do if time allows | Avoid — poor ROI |
This framework is used heavily in product management and agile development. The y-axis measures the value delivered; the x-axis measures the resources required. \"Quick wins\" (high impact, low effort) should always be done first. \"Thankless tasks\" (low impact, high effort) should be deprioritised or killed.
\n| Category | Meaning | Guideline |
|---|---|---|
| Must Have | Non-negotiable for this delivery | 60% of effort |
| Should Have | Important but not critical | 20% of effort |
| Could Have | Desirable if resources allow | 20% of effort |
| Won't Have | Explicitly out of scope | 0% (this round) |
MoSCoW is particularly useful for project scoping and sprint planning because the \"Won't Have\" category is explicitly acknowledged rather than silently deferred. Naming what you are not doing is as important as naming what you are doing — it prevents scope creep and sets stakeholder expectations.
\n| Scenario | Best framework | Why |
|---|---|---|
| Personal time management | Eisenhower | Separates your reactive habits from proactive priorities |
| Product feature prioritisation | Impact/Effort | Optimises for value delivered per engineering hour |
| Project scoping / sprint planning | MoSCoW | Creates explicit scope boundaries with stakeholder buy-in |
| Startup strategy | RICE scoring | Adds Reach, Impact, Confidence, and Effort for quantitative ranking |
Everything is \"high priority\": If every task is urgent and important, nothing is — the matrix becomes useless. Force-rank: no more than 20% of tasks should be in the top priority quadrant.
\nConfusing urgency with importance: A ringing phone is urgent but may not be important. A long-term business strategy is important but never urgent — until it becomes a crisis. The Eisenhower Matrix exists precisely to expose this confusion.
\nIgnoring the bottom-right quadrant: Items classified as \"major projects\" (high impact, high effort) often get indefinitely deferred in favour of quick wins. This is rational in the short term but catastrophic over years — it means the organisation never invests in transformative work.
\nHow many items should a priority matrix contain?
5–15 items per session. Fewer than 5 doesn't require a framework; more than 15 becomes overwhelming and defeats the purpose of visual prioritisation.
How often should I reprioritise?
Weekly for personal tasks, per sprint for product teams, quarterly for strategic initiatives. The cadence should match the rate of change in your context.
Can I combine frameworks?
Yes — use Eisenhower for personal tasks and Impact/Effort for team projects. Different scopes benefit from different lenses.
A habit streak counts the number of consecutive days you have performed a specific behaviour. The streak concept powers Duolingo's retention engine, Snapchat's engagement metrics, and Jerry Seinfeld's famous \"don't break the chain\" productivity method. The psychology is well-documented: streaks exploit loss aversion, create social commitment, and build automaticity — but they can also backfire.
\n| Mechanism | Research | Effect on habits |
|---|---|---|
| Loss aversion | Kahneman & Tversky, 1979 | Losing a 30-day streak feels worse than starting a new one feels good — so you do the habit to avoid the loss |
| Consistency principle | Cialdini, 2001 | Once you identify as \"someone who exercises daily,\" breaking the streak conflicts with self-image |
| Variable reward schedule | Skinner, 1957 | Milestones (10, 30, 100 days) provide intermittent rewards that sustain motivation |
| Automaticity | Lally et al., 2010 | After 66 days on average (range: 18–254), the behaviour becomes automatic and requires less willpower |
The frequently cited \"21 days to form a habit\" is a misquotation of Maxwell Maltz's 1960 observation about plastic surgery patients adjusting to new faces. The actual research (Lally et al., 2009, published in the European Journal of Social Psychology) found that habit formation takes 18 to 254 days, with a median of 66 days. Simple habits (drinking water) form faster; complex habits (exercising) take longer. Missing a single day did not significantly impact long-term habit formation.
\nAll-or-nothing thinking: A broken streak can trigger complete abandonment (\"I missed day 47, so I might as well give up\"). Research on the \"what-the-hell effect\" (Cochran & Tesser, 1996) shows that perceived failure on a self-control goal often leads to overconsumption in the opposite direction.
\nQuality degradation: To maintain a writing streak, some people write one sentence and count it as \"done.\" The streak is preserved but the practice quality has collapsed. Minimum viable effort preserves the metric while eroding the purpose.
\nGuilt and burnout: Streaks can transform an enjoyable activity into an obligation. If maintaining the streak causes anxiety on rest days, the tool is working against you.
\nAllow \"rest days\" without breaking: Some streak trackers let you designate 1–2 rest days per week that don't count against the streak. This mirrors how gym routines actually work — recovery is part of the programme.
\nTrack consistency rate, not just streaks: Doing the habit 26 out of 30 days (87% consistency) is better than a 14-day streak followed by complete abandonment. The Gen Code Tools streak tracker shows both metrics.
\nCelebrate milestones: 7 days, 30 days, 100 days, 365 days. Each milestone provides a dopamine reward that reinforces the behaviour.
\nBJ Fogg's \"Tiny Habits\" method links a new habit to an existing one: \"After I pour my morning coffee [existing habit], I will write in my journal for 5 minutes [new habit].\" Pairing the streak tracker with a specific trigger increases the likelihood of remembering and performing the habit.
\nDoes missing one day ruin everything?
No. Lally's research found that missing a single day had no measurable impact on long-term habit formation. The \"never miss twice\" rule (attributed to James Clear) is a practical heuristic: one miss is a rest; two misses is the start of a new (bad) pattern.
What's a good starter streak goal?
7 days. It's short enough to feel achievable, long enough to build initial momentum. After 7 days, extend to 30. After 30, the habit is likely establishing itself and the streak becomes self-sustaining.
Should I track multiple habits simultaneously?
Start with one or two. Research on ego depletion (Baumeister et al., 1998) suggests that willpower is a limited resource — though this finding is debated in recent literature. Practically, tracking fewer habits increases the success rate for each.
A goal calculator takes a large target (save $20,000, read 50 books, run a marathon) and breaks it into the daily or weekly actions required to achieve it by a specific date. The arithmetic is division — but the insight is in seeing how manageable (or how unrealistic) the daily requirement actually is.
\nDaily Action = (Target − Current Progress) / Days Remaining
| Goal | Target | Current | Days left | Daily action needed |
|---|---|---|---|---|
| Save money | $20,000 | $3,500 | 365 | $45.21/day |
| Read books | 50 books | 12 books | 214 | 1 book per 5.6 days |
| Lose weight | 20 lbs | 0 lbs lost | 180 | 0.78 lbs/week (safe rate) |
| Learn vocabulary | 3,000 words | 400 words | 365 | 7.1 words/day |
\"Save $20,000\" feels overwhelming. \"$45 per day\" feels manageable. The psychology is well-documented: Locke and Latham's Goal Setting Theory (1990, 2002) found that specific, challenging goals with clear metrics produce 20–25% better performance than vague intentions like \"do your best.\" The goal calculator converts vague aspirations into specific daily targets.
\n| Letter | Meaning | Calculator helps? |
|---|---|---|
| S | Specific | Yes — exact target number |
| M | Measurable | Yes — daily/weekly metrics |
| A | Achievable | Yes — reveals if the daily action is realistic |
| R | Relevant | No — that's your decision |
| T | Time-bound | Yes — deadline is an input |
Not all goals progress linearly. Language learning follows a logarithmic curve (rapid early progress, slower later). Weight loss follows a step function (plateaus are normal). Marathon training follows a periodised plan with deliberate rest weeks. The calculator provides a linear baseline; adjust your expectations based on the goal's typical progression pattern.
\nResearch on implementation intentions (Gollwitzer, 1999) shows that people who specify when, where, and how they will act on a goal are 2–3 times more likely to follow through. Combining the goal calculator with a habit tracker or calendar creates the specificity that implementation intentions require.
\nIf the calculator shows you need to save $200/day to hit your target, you have three options: extend the deadline, reduce the target, or increase your income/output rate. The calculator's value is in revealing this impossibility early, before six months of half-hearted effort and inevitable disappointment.
\nShould I include rest days?
Yes. If you plan to work toward your goal 5 days per week, divide by the number of active days, not calendar days. Sustainable goals account for rest and recovery.
What if I fall behind?
Recalculate with your current progress and remaining time. The new daily requirement will be higher, which either motivates a push or reveals that the timeline needs adjustment.
Can I use this for team goals?
Yes. Divide the daily target by team size to get individual contributions. This makes team accountability visible and equitable.
Walk into any office and you will find the same complaint repeated floor after floor: this meeting should have been an email. Yet the fix is rarely cancelling the meeting — it is building the agenda so the meeting cannot drift. The distinction matters, because an unstructured meeting of five people at an average salary costs around $400 per hour in loaded labour, and most organisations run dozens each week.
\n\nMost agendas are a list of topics, and a bare topic tells you what will be talked about without defining when the item is finished. A structured agenda item needs four fields that work together:
\n| Field | Purpose | Example |
|---|---|---|
| Type | Decision, discussion, or information | Decision |
| Owner | One named person, not a team | Priya |
| Timebox | Maximum minutes for the item | 10 |
| Outcome | What exists at the end that did not exist at the start | Launch date selected and recorded |
The type field does the most work. A decision item requires the decision-maker present and the options prepared in advance. A discussion item requires the people with context and no expectation of immediate resolution. An information item — and this is where real savings hide — usually needs no meeting at all; a written document covers it.
\n\n| Item | Type | Owner | Min | Outcome |
|---|---|---|---|---|
| Silent read of the proposal | Info | All | 8 | Everyone has read the document |
| Pick launch date: 14 or 28 Oct | Decision | Priya | 10 | Date chosen and entered into the project plan |
| Pricing objections from beta users | Discussion | Sam | 12 | Objections listed and rank-ordered |
| Owner for the migration risk | Decision | Priya | 5 | One name assigned to the risk register |
| Actions and owners read back | Info | Chair | 5 | Written actions confirmed by the room |
| Total | 40 | In a 45-minute booking |
Two deliberate design choices appear. The total is 40 minutes inside a 45-minute calendar slot, leaving genuine slack — Parkinson's law is real, and an agenda that fills the slot exactly always overruns. The meeting opens with silent reading rather than a slide presentation, a practice popularised at Amazon: reading the document in the room guarantees a prepared audience without relying on anyone having done pre-work, and it surfaces sharper questions than a slide walkthrough can.
\n\nPut the purpose at the top in one sentence, phrased as what will be different afterwards. Not \"discuss Q4 planning\" but \"choose between the two Q4 scopes so engineering can start on Monday.\" If you cannot write that sentence, the meeting is not ready. This test alone cancels a surprising share of recurring meetings, and cancelling an unnecessary meeting is worth more than any improvement to how that meeting runs.
\n\n| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Round-table status updates | Eight people sit while one talks; the others check email | Move updates to a shared document; use the meeting only for blockers |
| \"Any other business\" | Open-ended items expand to fill remaining time | End the meeting early instead; AOB goes to the next agenda if needed |
| Back-to-back items with no owner | Nobody prepares; discussion spins | Assign one named owner per item who comes prepared |
| Information items presented live | Reading is 3-4 times faster than listening; live presentation wastes the group's time | Circulate the document before or at the top of the meeting |
Recurring meetings are where hidden costs accumulate. A weekly 30-minute sync with six people is 156 hours per year — nearly a month of full-time work. Apply two rules: first, every recurring meeting must have a standing agenda template with defined outcomes, not just topic headings. Second, review the guest list quarterly and remove anyone who has not spoken or been referenced in the last four sessions.
\n\nA 2022 Microsoft study of 31,000 workers found that the average employee spends 252 percent more time in meetings than before the pandemic. Separately, a Harvard Business Review analysis found that 71 percent of senior managers rated meetings as unproductive. The data consistently shows that preparation — not duration, not technology, not facilitation style — is the strongest predictor of whether attendees rate a meeting as valuable. A structured agenda is the single most effective form of meeting preparation.
\n\nAn agenda is necessary but not sufficient. It cannot fix a meeting where the wrong people are invited, where the decision-maker is absent, or where the pre-read was never written. It works best when combined with three other disciplines: a clear purpose statement at the top, a named facilitator who enforces timeboxes, and written actions distributed within 30 minutes of the meeting ending.
\n\nHow long should a meeting agenda be?
Match the number of items to the meeting length. A 30-minute meeting handles three to four items well; a 60-minute meeting handles five to six. More than six items usually means the meeting should be split.
Should you share the agenda in advance?
Always, at least 24 hours before. Sharing the agenda gives attendees time to prepare and, critically, to flag items that are unnecessary or that need different attendees.
What if an important topic arises mid-meeting?
Acknowledge it, assign an owner, and add it to the next meeting's agenda with a proper timebox. Letting unplanned topics hijack a structured meeting destroys the discipline that makes agendas valuable.
A focus timer structures work into timed intervals — typically 25 minutes of focused work followed by a 5-minute break (the Pomodoro Technique) — based on the cognitive science principle that attention is a depletable resource that recovers with brief rest. The tool is simple; the psychology behind it is well-supported.
\nAttention research identifies three mechanisms that make timed work sessions more productive than open-ended effort:
\n| Mechanism | Research basis | Practical effect |
|---|---|---|
| Parkinson's Law | \"Work expands to fill the time available\" (Parkinson, 1955) | A 25-minute constraint forces prioritisation and reduces procrastination |
| Vigilance decrement | Attention quality declines after 20–25 minutes of sustained focus (Mackworth, 1948) | Brief breaks reset attentional resources |
| Zeigarnik Effect | Incomplete tasks create mental tension that promotes continuation (Zeigarnik, 1927) | Starting a timer creates commitment; the break feels earned rather than lazy |
| Protocol | Work interval | Short break | Long break (after N cycles) |
|---|---|---|---|
| Classic Pomodoro | 25 min | 5 min | 15–30 min after 4 cycles |
| 52/17 (DeskTime study) | 52 min | 17 min | — |
| 90-minute ultradian | 90 min | 20 min | — |
| Deep work blocks | 60–120 min | 15–20 min | — |
The 52/17 split comes from a DeskTime study that tracked the habits of the top 10% most productive users of their time-tracking software. The 90-minute cycle aligns with ultradian rhythms — natural oscillations in alertness that occur roughly every 90 minutes throughout the day.
\nThe purpose of the break is to restore attentional resources. Effective break activities: walking, stretching, looking at distant objects (reduces eye strain), drinking water. Counterproductive break activities: checking social media (which depletes the same attentional resources), reading email (which introduces new cognitive load), and skipping the break entirely.
\nCal Newport's Deep Work (2016) argues that the ability to concentrate without distraction is becoming both rarer and more valuable. A 2023 University of California study found that the average office worker is interrupted every 3 minutes and 5 seconds. After each interruption, it takes an average of 23 minutes and 15 seconds to return to the original task. A focus timer with notifications silenced creates a protected block that reduces interruption frequency.
\nTimed work sessions are particularly effective for people with ADHD because they externalise the time management function that ADHD impairs. The timer provides the external structure that the internal executive function struggles to maintain. Many ADHD coaches recommend starting with shorter intervals (10–15 minutes) and gradually increasing as the habit develops.
\nWhat if I'm in flow when the timer rings?
If you are deeply focused and productive, extend the session to a natural stopping point and then take a slightly longer break. The timer is a guide, not a mandate. However, consistently ignoring the timer defeats its purpose.
Does this work for creative tasks?
Yes, with adjustment. Creative tasks often require longer ramp-up time. Use 45- or 90-minute blocks instead of 25 minutes. The break structure still applies — creativity benefits from incubation periods.
Should I track how many sessions I complete?
Yes — tracking completed sessions per day gives you an objective measure of productive time. Most knowledge workers complete 8–12 Pomodoro sessions per day, which translates to 3.5–5 hours of genuinely focused work. This is consistent with research suggesting that 4 hours of deep work per day is the sustainable maximum for most people.
Cognitive load is the total amount of mental effort being used by working memory at any given moment. The concept comes from educational psychology (John Sweller, 1988), but it applies to every domain where humans process information: software interfaces, workplace multitasking, study sessions, and decision-making under pressure.
\n| Type | Definition | Example | Can you reduce it? |
|---|---|---|---|
| Intrinsic | Complexity inherent in the material | Learning calculus is harder than learning arithmetic | Not directly — it's fixed by the topic |
| Extraneous | Load caused by poor design or instruction | A confusing UI, a badly structured lecture | Yes — this is where design improvements help |
| Germane | Load devoted to building mental models (learning) | Making connections between new and existing knowledge | You want to increase this |
The total of all three types must not exceed working memory capacity (approximately 4 ± 1 items according to Cowan's 2001 revision of Miller's original 7 ± 2). The goal of good design — whether in software, teaching, or communication — is to minimise extraneous load so that capacity is available for intrinsic and germane processing.
\nMiller's famous 1956 paper proposed 7 ± 2 items, but subsequent research (Cowan, 2001; Oberauer, 2002) suggests the true limit is closer to 4 items for unrelated chunks. Chunking — grouping items into meaningful units — extends effective capacity. A phone number like 4155551234 is 10 digits (exceeding capacity) but 3 chunks: 415-555-1234 (within capacity).
\n| Activity | Estimated cognitive load | Impact |
|---|---|---|
| Reading email while on a call | High extraneous | Both tasks performed poorly |
| Writing code with Slack open | High extraneous | Error rate doubles (Microsoft Research) |
| Studying with spaced retrieval | High germane | Better long-term retention |
| Using a well-designed form | Low extraneous | Faster completion, fewer errors |
In software design: Progressive disclosure (showing only relevant options), consistent patterns, sensible defaults, and clear error messages reduce extraneous load. Every unnecessary UI element consumes working memory.
\nIn communication: Bullet points, headings, tables, and the inverted pyramid structure (conclusion first, details after) reduce the load on the reader. A wall of text requires the reader to build their own structure — that's extraneous load transferred from writer to reader.
\nIn meetings: Pre-read documents reduce the cognitive load of real-time processing. Agendas reduce the load of wondering \"what are we doing here?\" Timeboxes reduce the load of uncertainty about duration.
\nTrue multitasking — performing two cognitive tasks simultaneously — is a myth for tasks requiring attention. What people call multitasking is rapid task switching, which incurs a \"switch cost\" of 10–40% of productive time (Rubinstein, Meyer & Evans, 2001). The cognitive load calculator estimates this cost based on the number of concurrent tasks and their individual complexity.
\nIs cognitive load the same as stress?
No — high cognitive load can be enjoyable (a challenging puzzle in flow state is high intrinsic + high germane load). Stress is an emotional response that may result from sustained overload but is a separate phenomenon.
Can I increase my working memory capacity?
Working memory training (n-back tasks) shows limited transfer to real-world tasks. More effective strategies: reduce extraneous load through better tools and habits, and increase chunking ability through expertise in your domain.
How is cognitive load measured?
In research: subjective ratings (NASA-TLX), physiological measures (pupil dilation, fMRI), and dual-task performance. In practice: task completion time and error rate are reliable proxies.
Every meeting is an investment of collective time. A 30-minute meeting with six people at a loaded cost of $75 per hour spends $225 of organisational resources. The question is whether the meeting produced at least $225 in value — and most organisations never ask.
\n\nMeeting ROI = (Value of Outcomes − Cost of Meeting) / Cost of Meeting × 100%
The cost side is straightforward: attendees × loaded hourly rate × duration. The value side is harder to quantify but not impossible. A meeting that produces a signed decision avoids days or weeks of email threads. A meeting that unblocks a team saves idle engineering time. A meeting that reaches no conclusion and generates no action items produced zero value at a definite cost.
\n\n| Outcome type | Value signal | Approximate worth |
|---|---|---|
| Binding decision made | High — eliminates uncertainty | 2–10× meeting cost |
| Blocker removed | High — restores productivity | Idle team cost per hour × hours saved |
| Action items assigned | Medium — progress enabled | Depends on follow-through rate |
| Information shared | Low — could have been async | Near zero marginal value over email |
| No outcomes documented | Zero | Negative (cost incurred, nothing gained) |
After any meeting, ask five questions. If you answer \"no\" to three or more, the meeting was likely not worth the cost:
\nA 2022 Harvard Business Review study surveyed 182 senior managers and found that 71% rated meetings as unproductive and inefficient, 65% said meetings kept them from completing their own work, and 64% said meetings came at the expense of deep thinking. Yet the average number of meetings per week has increased steadily since 2020, driven by remote work and the ease of scheduling video calls.
\n\nMeeting cost calculators measure direct cost (labour × time), but the larger cost is opportunity cost — what each attendee would have accomplished instead. A senior engineer's most valuable work happens in uninterrupted blocks of 90 minutes or more. A mid-morning meeting fragments the morning into two sub-optimal blocks. The engineering output lost is real but invisible on any dashboard.
\n\nConflict resolution: When two teams disagree on priorities or approach, a live conversation with a decision-maker present resolves the issue in 30 minutes. The same conflict in Slack can persist for days.
\nComplex planning: Multi-dependency project planning benefits from real-time whiteboarding where participants can challenge assumptions and adjust sequences immediately.
\nRelationship building: Early-stage team formation, new-hire onboarding, and cross-team introductions generate social capital that increases future collaboration speed. These meetings are hard to quantify but clearly valuable.
\n\n| Meeting type | Alternative | Time savings |
|---|---|---|
| Status update | Async standup (Slack, email) | 80–90% |
| Information broadcast | Recorded video (Loom, etc.) | 60–70% |
| Feedback review | Shared document with inline comments | 50–60% |
| Brainstorm | Async idea board (Miro, FigJam) → live synthesis session | 30–40% |
How do I calculate loaded cost if HR won't share salary data?
Use industry benchmarks. For US tech companies, a reasonable estimate is $50–$90/hour for individual contributors and $100–$180/hour for managers and directors.
Should I include the facilitator's prep time?
Yes. If someone spends 30 minutes preparing the agenda and materials, that is 30 minutes of labour cost that should be included in the meeting's total cost.
What is a good meeting-to-deep-work ratio?
Research suggests that knowledge workers are most productive when meetings occupy no more than 30–40% of their work week. Above 50%, productivity and job satisfaction decline measurably.
Procrastination is not free. Every day a task is delayed has a cost — sometimes financial (late fees, lost interest), sometimes operational (blocked teammates, missed windows), and always in opportunity cost (what you could have done instead). The procrastination cost calculator quantifies this cost to convert an abstract \"I should do this\" into a concrete \"every day I delay costs me $X.\"
\nProcrastination Cost = Daily Opportunity Cost × Days Delayed + Direct Penalties
| Scenario | Daily opportunity cost | Days delayed | Direct penalty | Total cost |
|---|---|---|---|---|
| Filing taxes late | Interest accrual: ~$1.40/day per $10K owed | 30 | 5% failure-to-file penalty | $542+ |
| Delaying investment of $10,000 | $1.64/day at 6% annual return | 90 | None | $148 |
| Not cancelling unused subscription | $0.50/day ($15/month) | 180 | None | $90 |
| Postponing a job application | Salary gap: $220/day (at $80K/year) | 14 | Position may fill | $3,080+ |
Delaying a $10,000 investment by one year at 7% annual return costs $700 in the first year alone. Over 20 years, that one-year delay costs $3,870 (the future value of $700 compounded at 7% for 20 years). Over 30 years, it costs $7,612. The cost of procrastination compounds alongside the returns you miss.
\nPiers Steel's meta-analysis of 216 studies (Psychological Bulletin, 2007) found that procrastination is driven by four factors, captured in the Temporal Motivation Theory equation:
\nMotivation = (Expectancy × Value) / (Impulsiveness × Delay)
| Factor | Effect | Intervention |
|---|---|---|
| Low expectancy (self-doubt) | \"I probably can't do this well\" | Break task into smaller, achievable steps |
| Low value (boring task) | \"This isn't interesting or rewarding\" | Pair with reward; connect to larger goal |
| High impulsiveness (distraction) | \"I'll do it after this video\" | Remove distractions; use a focus timer |
| High delay (distant deadline) | \"It's not due for weeks\" | Create intermediate deadlines; use the procrastination cost calculator |
Research by Timothy Pychyl (Carleton University) and Fuschia Sirois (University of Sheffield) frames procrastination as an emotion regulation problem, not a time management problem. People procrastinate to avoid negative emotions associated with the task (boredom, anxiety, frustration). The task gets done eventually — but only after the emotional cost of delay (guilt, stress) exceeds the emotional cost of doing the task. Making the cost of delay visible and quantitative can shift this tipping point earlier.
\nIs some procrastination productive?
Yes — \"structured procrastination\" (John Perry, Stanford) involves doing useful secondary tasks while avoiding the primary one. And some tasks genuinely benefit from incubation time. But chronic procrastination on important tasks is costly by any measure.
How accurate is the cost calculation?
Direct costs (late fees, missed returns) are precise. Opportunity costs are estimates based on your hourly rate and the task's value. The number doesn't need to be exact — its purpose is to make the abstract cost of delay concrete and motivating.
Does the cost calculator help with ADHD-related procrastination?
It can help by externalising the consequences that ADHD brains struggle to internalise. However, ADHD procrastination has neurological underpinnings that go beyond motivation — executive function support tools, accountability partners, and professional coaching are often more effective than cost quantification alone.
The subject line is the most important sentence in any email. Mailchimp's analysis of 12 billion emails found that subject lines account for 47% of the decision to open or ignore. Yet most subject lines are written in seconds, as an afterthought, after spending 30 minutes crafting the body. The email subject line scorer evaluates your subject against research-backed criteria and suggests improvements.
\n| Factor | Weight | Why it matters |
|---|---|---|
| Length (6–10 words ideal) | 20% | Mobile screens truncate at ~40 characters; 78% of email is read on mobile |
| Specificity (numbers, names, dates) | 20% | Specific subjects outperform vague ones by 22% in A/B tests (Campaign Monitor) |
| Urgency without spam triggers | 15% | \"Limited time\" works; \"ACT NOW!!!\" triggers spam filters |
| Personalisation | 15% | Subjects with the recipient's name or company have 26% higher open rates (Experian) |
| Clarity of value proposition | 15% | The reader must know what they get by opening within 2 seconds |
| Absence of spam triggers | 15% | ALL CAPS, excessive punctuation, and words like \"free\" or \"guarantee\" reduce deliverability |
| Subject line | Score | Why |
|---|---|---|
| Your Q3 report is ready — 3 key takeaways inside | 92 | Specific, clear value, moderate length, no spam triggers |
| Quick question about Thursday's meeting | 85 | Short, specific day, conversational tone |
| Newsletter #47 | 38 | No value proposition, no reason to open |
| 🔥🔥🔥 AMAZING DEAL DON'T MISS OUT!!! | 12 | All caps, excessive emoji, spam triggers, no specificity |
Research from Marketo found that subject lines with 7 words and 41 characters produce the highest engagement rates. Below 4 words, the subject feels incomplete. Above 12 words, mobile truncation cuts the message. The sweet spot is 6–10 words, which balances specificity with scannability.
\nPower words that increase opens: you, your, new, how, why, quick, update, invitation, confirmed, results, [name], [number].
\nSpam trigger words that decrease deliverability: free, guarantee, no obligation, act now, limited time offer, congratulations, winner, click here, urgent. These words alone don't guarantee spam classification, but they contribute to spam score in combination with other signals.
\nThe only way to know what works for your specific audience is to test. Send variant A to 15% of your list, variant B to another 15%, wait 2–4 hours, then send the winner to the remaining 70%. Most email platforms (Mailchimp, ConvertKit, Brevo) automate this process. Test one variable at a time: length, specificity, personalisation, or emoji use — never all at once.
\nB2B emails perform better with formal, specific subjects that reference the recipient's company or industry. B2C emails can use more emotional language, emoji, and urgency. A 2023 Litmus report found that B2B open rates average 21.3% while B2C averages 19.7%, suggesting that B2B audiences are slightly more responsive — likely because they receive fewer promotional emails.
\nShould I use emoji in subject lines?
Data is mixed. A 2022 Return Path study found that emoji increase open rates by 3–5% in B2C but decrease them by 2% in B2B. Use sparingly (one emoji maximum) and test with your audience.
Does the preview text matter?
Yes — the preview text (preheader) is the second most-read element after the subject. Treat it as a continuation of the subject line, not a repeat. Together, subject + preview should form a complete value proposition.
Can I reuse high-performing subject lines?
Yes, with modifications. Exact repeats trigger spam filters and bore subscribers. Change the specifics (numbers, dates) while keeping the structure.
Negotiation power — also called bargaining leverage — is determined by factors that exist before anyone sits down at the table. Your BATNA (Best Alternative to a Negotiated Agreement), information asymmetry, time pressure, and relationship dynamics collectively determine how much leverage you have. The negotiation power calculator evaluates these factors and produces a score that tells you whether to push hard, compromise, or walk away.
\n| Component | Weight | What it measures |
|---|---|---|
| BATNA strength | 30% | How good is your alternative if this negotiation fails? |
| Information advantage | 20% | Do you know more about market rates, competitor offers, or the other party's constraints? |
| Time pressure differential | 20% | Who needs a deal sooner? The party under time pressure concedes more. |
| Relationship leverage | 15% | Does the other party value the relationship beyond this transaction? |
| Scarcity of alternatives | 15% | How many other options does the other party have? |
Coined by Fisher and Ury in Getting to Yes (1981), BATNA is your best course of action if the current negotiation fails. A job candidate with two competing offers has a strong BATNA. A candidate with no other prospects has a weak one. The strength of your BATNA determines your walk-away point — the minimum acceptable outcome below which you prefer the alternative.
\nImproving your BATNA before negotiating is often more effective than improving your negotiation tactics during the conversation. Create alternatives: apply to more jobs, get competing bids, develop in-house capabilities. Every viable alternative strengthens your position.
\nKnowing the other party's constraints (budget ceiling, deadline pressure, competitive alternatives) lets you frame proposals that fit within their limits while maximising your outcome. But negotiation research (Galinsky & Mussweiler, 2001) also shows that making the first offer anchors the negotiation in your favour — which requires revealing information. The skill is in revealing enough to anchor without revealing so much that you lose leverage.
\nThe party who needs an agreement sooner is at a disadvantage because they cannot afford to walk away or extend the process. Strategies: if you're under time pressure, don't reveal it. If the other party is under time pressure, slow down — patience becomes a negotiating tool.
\n| Score range | Position | Strategy |
|---|---|---|
| 80–100 | Strong leverage | Push for your ideal outcome; make the first offer to anchor high |
| 60–79 | Moderate leverage | Negotiate firmly but be prepared to compromise on secondary issues |
| 40–59 | Balanced | Focus on creative solutions (expanding the pie) rather than claiming a larger share |
| 20–39 | Weak leverage | Improve your BATNA before negotiating; delay if possible |
| 0–19 | Very weak | Consider whether this negotiation is worth entering at all |
Can I improve my score before negotiating?
Yes — and you should. The most effective improvements are: getting competing offers (BATNA), researching market rates (information), and removing artificial deadlines (time pressure).
Does a high score guarantee a good outcome?
No. Power is potential; execution matters. Poor communication, emotional reactions, or failing to listen can waste strong leverage.
Is negotiation power zero-sum?
Not necessarily. Integrative negotiation (expanding the pie) can increase both parties' power by finding solutions that create value neither party anticipated.
Return on Investment is a financial concept: (gain − cost) / cost × 100%. Life ROI applies the same logic to non-financial decisions by assigning approximate monetary or utility values to how you spend your time. A $50 gym membership used 20 times per month has a higher ROI than a $200 course never completed. The calculator makes these comparisons explicit.
\nLife ROI = (Value Gained − Total Cost) / Total Cost × 100%
Total cost includes money spent plus the opportunity cost of time. Value gained includes direct benefits (income increase, health improvement) and indirect benefits (enjoyment, stress reduction).
\n| Activity | Cost (money + time value) | Estimated value gained | ROI |
|---|---|---|---|
| Learning a high-demand skill (e.g., SQL) | $200 course + 40 hours × $30/hr = $1,400 | $8,000 salary increase over 2 years | 471% |
| Gym membership (used regularly) | $600/year + 156 hours × $30/hr = $5,280 | $3,000 saved health costs + quality of life | −43% (but health is non-negotiable) |
| Streaming subscription (used daily) | $180/year | 365 hours of entertainment valued at $5/hr = $1,825 | 914% |
| Online course (never completed) | $400 | $0 | −100% |
The most expensive part of most activities is not the money — it's the time. A \"free\" webinar that takes 2 hours costs $60–$120 in opportunity cost for a professional earning $30–$60 per hour. If the webinar delivers no actionable value, its real cost is $60–$120, not $0.
\nMalcolm Gladwell popularised the idea that mastery requires 10,000 hours of deliberate practice. At $40/hour opportunity cost, 10,000 hours represents a $400,000 investment. The question is whether the mastery produces returns that justify this cost. For a professional musician, surgeon, or elite athlete, the answer is often yes. For a casual hobbyist, the calculation is different — and that's fine, because not everything needs to have positive financial ROI.
\nEducation: A $100,000 degree that increases lifetime earnings by $1,000,000 has a 900% ROI. A $100,000 degree that leads to the same career as a $10,000 certification has a much lower ROI. The ROI calculator doesn't tell you what to value — it clarifies what you're paying and what you're getting.
\nHealth: Preventive health activities (exercise, dental checkups, sleep optimisation) have extremely high ROI when measured against the cost of reactive healthcare. A $100/month gym membership is cheaper than a single emergency room visit.
\nRelationships: Time invested in close relationships has strong evidence of improving longevity and well-being (Harvard Study of Adult Development, 75+ years of data). The ROI is not financial but is measurable in life satisfaction and health outcomes.
\nNot everything valuable is measurable, and not everything measurable is valuable. Using ROI to evaluate every life decision leads to an exhausting optimisation mindset that ignores intrinsic motivation, serendipity, and the value of activities done purely for enjoyment. The calculator is a lens, not a life philosophy.
\nHow do I value my time?
Start with your hourly income as a baseline. If you earn $60,000/year, your time is worth approximately $30/hour. Some people use their freelance rate or the cost of hiring someone to do the task instead.
Can ROI be applied to leisure activities?
Yes, but the \"return\" is subjective enjoyment, stress relief, or social connection rather than money. If an activity brings consistent enjoyment at a reasonable cost, the ROI is positive by your own valuation.
What if an activity has delayed returns?
Discount future returns appropriately. A skill learned today that pays off in 5 years is worth less in present value than one that pays off immediately. Use a discount rate of 5–10% per year as a rough guide.
The decision coin flip is not about letting chance decide — it is about using randomness to reveal what you actually want. The moment the coin is in the air, most people discover they are hoping for one outcome over the other. That hope is the decision. The coin is the tool that surfaces it.
\nEnter two (or more) options. The tool randomly selects one. You then rate your emotional response: relief, disappointment, or indifference. If you feel relief, the random choice aligned with your preference. If you feel disappointed, the other option is what you actually want. If you feel indifferent, the options are genuinely equivalent and random selection is efficient.
\n| Reaction to result | What it reveals | Action |
|---|---|---|
| Relief | You wanted this option all along | Choose this option with confidence |
| Disappointment | You wanted the other option | Choose the other option |
| Indifference | The options are genuinely equal | Accept the random result — further deliberation wastes time |
Low-stakes decisions: What to eat for lunch, which movie to watch, which route to take to work. The cognitive cost of deliberating exceeds the benefit of choosing optimally. Research by Sheena Iyengar (Columbia) found that excessive choice reduces satisfaction — the famous \"jam study\" showed that shoppers presented with 24 jam varieties were less likely to buy than those presented with 6.
\nBreaking analysis paralysis: When two options are roughly equivalent and you've been deliberating for more than 10 minutes, the marginal value of additional thinking approaches zero. A random choice ends the deliberation and frees cognitive resources for more important decisions.
\nFair allocation: Splitting tasks, assigning presentation order, or choosing who goes first in a game. Randomness is objectively fair and perceived as fair, avoiding interpersonal conflict.
\nHigh-stakes irreversible decisions: Career changes, major purchases, medical treatment choices. These warrant structured decision-making (decision matrices, pro/con lists, consultation with experts).
\nEthical decisions: Right and wrong are not coin-flip territory. Ethical dilemmas require principled reasoning, not randomisation.
\nDecisions with available data: If data exists that distinguishes the options (reviews, statistics, expert recommendations), using it is strictly better than randomising.
\nBarry Schwartz's The Paradox of Choice (2004) argues that more options lead to worse decisions and lower satisfaction. \"Maximisers\" (people who try to find the best option) experience more anxiety and regret than \"satisficers\" (people who choose the first good-enough option). The coin flip is a satisficing tool — it short-circuits the maximiser's endless comparison loop.
\nGoogle famously used random A/B testing to settle debates between designers (testing 41 shades of blue for a link colour). When experts disagree and data is ambiguous, a randomised test produces an empirical answer faster than continued debate. The coin flip is the simplest version of this principle.
\nIs the digital coin truly random?
The tool uses cryptographic randomness (crypto.getRandomValues in JavaScript), which is computationally indistinguishable from true randomness for practical purposes. It is not a physical coin flip, but it is unbiased.
Can I flip for more than two options?
Yes — enter multiple options and the tool selects one at random with equal probability. For weighted choices (where some options should be more likely), use the weighted random decision tool instead.
What if I keep flipping until I get the answer I want?
That is the tool working exactly as intended. The repeated flipping reveals your preference. Choose the option you keep hoping for and stop flipping.
Every name-number method maps letters to digits and sums them. There are three common mappings, and they disagree.
Ordinal: A = 1 through Z = 26.
Pythagorean cycles 1 to 9 across the alphabet:
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|---|---|---|---|---|---|---|---|---|
| A J S | B K T | C L U | D M V | E N W | F O X | G P Y | H Q Z | I R |
Chaldean uses 1 to 8 only, with an irregular mapping said to derive from sound rather than alphabet position, and it reserves 9 as never assigned to a letter.
Take MARIA.
That the ordinal and Pythagorean results match is not coincidence, and the reason is the most interesting thing on this page.
Repeatedly summing digits until one remains gives the digital root, and the digital root of any number equals that number modulo 9, with multiples of 9 giving 9 rather than 0. This is the old accountancy trick called casting out nines, and it works because 10 leaves remainder 1 when divided by 9, so every place value contributes its digit unchanged.
Now look at the Pythagorean table: it assigns each letter its alphabet position reduced mod 9. A is 1 and J is the tenth letter, also 1. R is eighteenth and gets 9, which is 18 mod 9 expressed as 9 instead of 0.
So the Pythagorean sum is congruent to the ordinal sum mod 9 — and since the final reduction is itself a mod 9 operation, the two systems can never produce different answers. Chaldean differs only because its mapping is not alphabet position mod 9.
A practical consequence: any anagram has the identical value, since addition is commutative. MARIA, AMIRA and RAIMA all give 6. Whatever the number is supposed to describe, it cannot distinguish between names built from the same letters.
Most traditions leave 11, 22 and sometimes 33 unreduced, calling them master numbers. Practitioners also distinguish the full-name value from the vowels-only figure and the consonants-only figure, and they disagree about whether to use the birth name, the current legal name, or the name you actually go by.
That last disagreement is worth sitting with, because it has no resolution within the system.
Nothing about your personality, future, compatibility or fortune. There is no evidence that name numbers predict anything about a person, and no proposed mechanism by which the Latin alphabet position of letters chosen by your parents could influence your character.
The reason readings nonetheless feel accurate is well studied and has a name. In a classic 1948 demonstration, students completed a personality test and were each handed what they believed was an individual profile. Every student received the same text, assembled from vague statements, and they rated it as highly accurate — averaging over 4 out of 5. This is the Forer effect, and it works because statements like you have a great deal of unused capacity or at times you are outgoing and at other times reserved are true of nearly everyone while feeling personally observed.
Add confirmation bias — remembering the parts that fit and forgetting the parts that did not — and a system with nine possible outputs describing eight billion people will produce hits constantly.
Treat this as what it is: a small piece of number theory with a long cultural history, and an entertaining thing to compute. It is not a basis for decisions about people, relationships, hiring or anything else with consequences.
Neither, in any testable sense. Chaldean is often presented as older and therefore more authentic; age is not evidence. They are different conventions producing different numbers.
Practitioners disagree, which is itself informative. If you are doing this for interest, try both and notice that you prefer whichever reading is more flattering.
Related but distinct. Gematria is a Hebrew tradition in which letters have established numeric values used for textual interpretation, with a long scholarly history. Modern name numerology borrows the arithmetic idea and applies it to Latin letters, which is a much more recent invention.
No. Whatever you type is processed in your browser and nothing is transmitted or saved.
" } }