DEV Community: EvvyTools

How to Verify File Integrity Using SHA-256 Checksums

EvvyTools — Tue, 26 May 2026 11:07:05 +0000

Downloading a software package, a binary, or a large dataset from the internet means trusting that what you received is what the author published. Checksums are how you verify that trust. The file's author computes a hash before publishing; you compute the same hash after downloading; if the values match, the file is intact and unmodified.

SHA-256 is the algorithm you should use for this. MD5 and SHA-1 checksums still appear for older projects, but both have demonstrated collision vulnerabilities that make them unsuitable for integrity verification where tampering is a concern. The SHA-2 family that includes SHA-256 has no known practical collision vulnerability. If you're choosing an algorithm for new file verification workflows, SHA-256 is the default.

Step 1: Find the Published Checksum

Most serious software projects publish checksums on their download page or in a separate checksums file. Common patterns:

A file named SHA256SUMS, checksums.txt, or sha256sums.txt listed alongside the download
A hash value next to the download link, labeled as SHA-256 or sha256
A detached PGP signature file covering the checksum file, adding a layer of authenticity verification on top of the integrity check

If the project only publishes MD5 checksums, you can still verify against them. An MD5 match tells you the file wasn't accidentally corrupted in transit. It doesn't guarantee the file wasn't intentionally modified by an attacker who could compute a matching MD5 for a modified file, which is now practical with consumer hardware.

For security-critical downloads (operating system images, cryptographic tools, container runtimes), prefer projects that publish SHA-256 checksums and verify them. The OWASP guidance on secure software distribution covers why this matters in web application and DevOps contexts.

Step 2: Compute the Hash of the Downloaded File

On the command line, this is straightforward on every platform.

Linux and macOS:

sha256sum /path/to/downloaded-file.zip

This prints the SHA-256 hash followed by the filename.

macOS alternative (if sha256sum is not installed by default):

shasum -a 256 /path/to/downloaded-file.zip

Windows (PowerShell):

Get-FileHash -Path "C:\path\to\downloaded-file.zip" -Algorithm SHA256

In scripting and automation contexts, Python provides the hashlib library for computing file hashes programmatically:

import hashlib

def sha256_file(path):
    h = hashlib.sha256()
    with open(path, 'rb') as f:
        for chunk in iter(lambda: f.read(65536), b''):
            h.update(chunk)
    return h.hexdigest()

Reading in chunks avoids loading the entire file into memory, which matters for large files like OS images or database dumps. The chunk size of 65536 bytes (64 KB) is a reasonable default that balances memory usage and I/O efficiency.

For text content or strings (not file hashing), the EvvyTools Hash Generator handles SHA-256 and the other major algorithms entirely in the browser. File hash verification for large files is better done on the command line since you don't upload the file anywhere.

Photo by Pixabay on Pexels

Step 3: Compare the Hashes

The hash you computed in Step 2 should exactly match the hash the project published. The comparison must be character-for-character with no differences.

Manual comparison: Copy both values into a text editor and compare them. SHA-256 hashes are 64 characters long. One wrong character anywhere means the file is different. A mismatch could mean the file was corrupted during download, served from a compromised mirror, or modified in transit.

Automated comparison on Linux/macOS: If the project provides a SHA256SUMS file, you can verify all listed files in one command:

sha256sum --check SHA256SUMS

This reads the SHA256SUMS file, computes hashes for all the listed files in the current directory, and reports which ones pass and which fail. Files that fail are listed with a clear mismatch message.

When hashes don't match:

First, try downloading again from the official source rather than a mirror. Corrupted downloads are the most common cause of mismatches, and a second download often resolves it. If you downloaded from a mirror, switch to the project's primary server. If the mismatch persists from the official source, report it to the project maintainers. A persistent mismatch from the canonical source could indicate a compromised distribution channel.

Step 4: Optionally Verify the Checksum File Itself

A SHA-256 hash tells you the file matches what was published. It doesn't tell you the published hash wasn't changed by someone who compromised the project's website or CDN between when the author published and when you downloaded.

For high-security scenarios, project maintainers often sign the checksum file with a PGP key. Verifying the PGP signature confirms the checksum file was signed by someone with the maintainer's private key:

gpg --verify SHA256SUMS.asc SHA256SUMS

This requires the maintainer's public key in your GPG keyring. Most projects that use this approach include instructions for importing their signing key on their download page or security documentation.

For most everyday software downloads, SHA-256 comparison alone is sufficient. PGP verification becomes more important for security-critical tools where you want to verify you have the genuine software from the genuine author, not just software that matches a potentially-compromised published hash.

Photo by ds_30 on Pixabay

Automating Checksum Verification in Build Pipelines

If you're downloading dependencies or artifacts in a build or CI/CD pipeline, automate the checksum verification rather than checking manually each time.

In a shell script:

EXPECTED_HASH="a7f3b...(paste the published SHA-256 here)"
ACTUAL_HASH=$(sha256sum downloaded-file.zip | awk '{print $1}')

if [ "$EXPECTED_HASH" != "$ACTUAL_HASH" ]; then
    echo "ERROR: Hash mismatch. Expected $EXPECTED_HASH, got $ACTUAL_HASH"
    exit 1
fi
echo "Hash verified successfully"

In Node.js using the built-in crypto module, Node.js provides crypto.createHash('sha256') for computing file hashes in a streaming fashion:

const crypto = require('crypto');
const fs = require('fs');

function sha256File(path) {
  return new Promise((resolve, reject) => {
    const hash = crypto.createHash('sha256');
    const stream = fs.createReadStream(path);
    stream.on('data', chunk => hash.update(chunk));
    stream.on('end', () => resolve(hash.digest('hex')));
    stream.on('error', reject);
  });
}

Automating this step means a compromised download will fail your build rather than proceed silently. For build pipelines that fetch external dependencies, this is a meaningful security improvement with low implementation cost. Pin to a specific version and verify the hash in the same pipeline step.

Understanding What Checksums Protect Against

SHA-256 checksums protect against accidental corruption (bit flips, incomplete transfers, disk errors) and intentional modification by an attacker who compromised the distribution channel after the hash was published.

They do not protect against a compromised build process. If the author's build server was compromised before the binary was created, the published hash is for the compromised binary. They also don't protect against malicious software published intentionally by the author. A hash match confirms you have what the author published, not that what the author published is safe.

For fully verifiable builds, some projects use reproducible builds: a deterministic build process where anyone can build the project from source and produce a binary with an identical hash. This is the strongest form of verification available and is increasingly common in security-conscious open-source projects.

The underlying mechanics of why SHA-256 is appropriate here and why MD5 and SHA-1 are not, including the collision vulnerabilities that disqualify them from integrity verification, are explained in the full article on How Cryptographic Hash Functions Work: MD5, SHA-1, SHA-256, and SHA-512 Explained.

How HMAC-SHA256 Works for API Request Signing

EvvyTools — Tue, 26 May 2026 11:07:02 +0000

SHA-256 tells you whether data has changed. HMAC-SHA256 tells you whether data has changed AND who created it. That second property is what makes HMAC the foundation of API request authentication, webhook verification, and secure message passing between services.

Most developers use HMAC-SHA256 regularly through platform integrations without thinking about how the signature is computed. When you need to implement verification yourself, write a custom signing scheme, or debug a signature mismatch, understanding the mechanics helps considerably. And when something breaks, knowing the construction tells you exactly where to look.

What HMAC Actually Is

HMAC stands for Hash-based Message Authentication Code. It wraps a hash function with a secret key in a specific way that gives the output a property a plain hash doesn't have: you can only reproduce it if you know the key.

The construction is defined in RFC 2104, which is worth reading if you want the formal specification. At a high level, HMAC works as follows:

Derive two sub-keys from the secret key (an outer key and an inner key) using XOR with padding constants.
Hash the inner key concatenated with the message.
Hash the outer key concatenated with the result of step 2.

The two-layer construction prevents a class of attacks called length-extension attacks, which affect plain SHA-256. An attacker who knows the SHA-256 hash of a message can compute the SHA-256 hash of the original message plus additional data without knowing the original message. HMAC's construction closes that attack surface entirely.

Photo by Alexas_Fotos on Pixabay

Why You Can't Just SHA-256 a Secret Key With a Message

A common mistake is computing SHA256(secret + message) or SHA256(message + secret) as a substitute for HMAC. Neither is secure.

SHA-256 is vulnerable to length-extension attacks: if you compute SHA256(secret + message), an attacker who knows the hash can compute SHA256(secret + message + extra_data) without knowing the secret. This allows them to forge valid hashes for extended messages.

HMAC-SHA256 avoids this by design. The two-layer construction breaks the algebraic property that makes length-extension attacks possible. This isn't an implementation choice you can match by being clever about how you concatenate inputs. Use a proper HMAC implementation from your language's standard library; don't hand-roll this construction.

The Signing and Verification Pattern

The signing side computes an HMAC over the payload using the shared secret:

signature = HMAC-SHA256(secret_key, message)

This signature is included with the request, typically as a header. Common header names are X-Hub-Signature-256 for GitHub webhooks and Stripe-Signature for Stripe webhooks.

The verification side receives the request, retrieves the shared secret (from a configuration store, never from the request itself), computes the same HMAC, and compares the result to the signature in the header:

expected = HMAC-SHA256(secret_key, request_body)
if constant_time_compare(expected, received_signature):
    proceed
else:
    reject

The comparison must be constant-time. A naive string comparison that short-circuits on the first mismatched character leaks timing information. An attacker can probe different signature values and observe which prefixes match by measuring response time differences. Most languages provide a timing-safe comparison function in their cryptography standard library. Use it.

Platform-Specific Variations

GitHub webhooks: The signature is HMAC-SHA256 of the raw request body, hex-encoded and prefixed with sha256=. The header is X-Hub-Signature-256.

Stripe webhooks: The payload includes a timestamp (t=) and a signature (v1=). The signed data is the timestamp and raw body concatenated: timestamp.body. This construction prevents replay attacks where a valid signature for an old payload is replayed with the same body content.

Shopify webhooks: HMAC-SHA256 of the raw request body, base64-encoded. The header is X-Shopify-Hmac-SHA256.

The variation is in encoding (hex vs base64), payload construction (raw body vs body plus timestamp), and header names. The core cryptographic primitive is the same across all of them.

Language-Specific Implementation

Most programming languages include HMAC support in their standard library. Python uses the hmac module:

import hmac
import hashlib

signature = hmac.new(
    key=secret.encode('utf-8'),
    msg=body.encode('utf-8'),
    digestmod=hashlib.sha256
).hexdigest()

Use hmac.compare_digest rather than == for the verification comparison. It provides constant-time comparison and prevents timing attacks. Passing the wrong type to compare_digest raises a TypeError, which is preferable to silently comparing bytes against a string and getting the wrong result.

Node.js uses the built-in crypto module:

const crypto = require('crypto');
const signature = crypto
  .createHmac('sha256', secret)
  .update(body)
  .digest('hex');

Use crypto.timingSafeEqual for the verification step. Both the expected and actual signature values must be the same byte length before comparing, since timingSafeEqual throws if they differ in length. Convert both to Buffer before passing them.

The important point in both cases: use the HMAC function from the standard library, not a hand-rolled implementation. Standard library implementations have been audited and handle edge cases correctly.

Photo by Lighten Up on Pexels

Debugging Signature Mismatches

Signature mismatches during implementation are almost always one of these problems:

Encoding mismatch. You're computing the HMAC on a UTF-8 string but comparing against a value computed on raw bytes, or vice versa. Be consistent about how you encode the message before hashing.

Raw body vs parsed body. Webhook verification requires hashing the raw request body as received, before any JSON parsing. If you hash the JSON output of your request parsing library, it may have different whitespace, different key ordering, or different Unicode normalization than the original body. Express.js, for example, requires enabling raw body capture separately from JSON parsing.

Secret key format. Some platforms provide the key as a hex string, some as plain text, some as base64. Use the raw bytes of the key, not the hex-encoded string representation, as the HMAC key input. Treating a hex string as the key directly produces a different HMAC than treating those same hex characters as a byte array.

Header prefix. GitHub's signature header value is sha256=<hex_digest>. If you're comparing the full header value against a raw hex digest, the comparison will always fail because of the prefix. Strip the prefix before comparing.

For quick testing during implementation, the Hash Generator on EvvyTools computes HMAC-SHA256 with a custom secret key, running entirely in the browser. Enter your test payload, set the secret, and compare the output against your implementation's result. Your test secrets don't go to any server.

Using HMAC for Signed URLs and Time-Limited Tokens

HMAC-SHA256 is also used outside of webhook contexts for signed URLs and short-lived tokens. The pattern is:

Assemble a string containing the data you want to authenticate: a user ID, an expiry timestamp, an action type.
Compute HMAC-SHA256 of that string with your signing key.
Append the signature to the URL or token.

On verification, reconstruct the data string from the URL or token parameters, compute the expected HMAC, and compare using a constant-time comparison function. Including a timestamp in the signed data prevents replay attacks: a signed URL becomes invalid after its expiry timestamp passes.

For the foundational explanation of how SHA-256 differs from earlier algorithms and why it's the current standard for constructions like HMAC, the article on How Cryptographic Hash Functions Work: MD5, SHA-1, SHA-256, and SHA-512 Explained covers the underlying properties that make SHA-256 appropriate here where SHA-1 and MD5 are not.

How Caffeine Half-Life Determines Your Safe Cut-Off Time

EvvyTools — Mon, 25 May 2026 10:53:05 +0000

Most people manage caffeine intake by volume - tracking how many cups they drink rather than how much caffeine is active in their system at any given time. The problem with that approach is that caffeine does not stop affecting you when you finish the drink. It stays pharmacologically active in your bloodstream for hours, and the rate at which it clears determines whether an afternoon coffee disrupts that night's sleep.

Understanding caffeine's half-life gives you a more precise tool for timing than "no coffee after 2pm" rules that ignore body weight, metabolic rate, and individual variation.

What Half-Life Means in Pharmacokinetics

Half-life is a pharmacokinetic concept that describes how long it takes for the concentration of a substance in the blood to decrease by 50%. It applies to medications, alcohol, and caffeine in the same way: each half-life period cuts the remaining concentration in half.

Caffeine's half-life in healthy adults without complicating factors is approximately 5-6 hours. This means:

If you consume 200mg of caffeine at 12:00pm:
- At 5:00pm: ~100mg still active (~50% remaining)
- At 10:00pm: ~50mg still active (~25% remaining)
- At 3:00am: ~25mg still active (~12.5% remaining)

The implication for a person sleeping at 11pm: they still have roughly 50mg of caffeine active in their system at bedtime. Fifty milligrams is not a large dose - it is less than half a typical cup of coffee - but it is enough to reduce slow-wave sleep, even when it does not prevent falling asleep.

The Distinction Between Sleep Latency and Sleep Quality

This is where many people make an error. They report that caffeine "doesn't affect their sleep" because they can fall asleep at their usual time after afternoon caffeine. That is a true observation about sleep latency (time to fall asleep) but not about sleep quality.

Caffeine suppresses slow-wave sleep, also called deep sleep or N3 sleep, even when it does not meaningfully delay sleep onset. Slow-wave sleep is the most physically restorative sleep stage - the phase where growth hormone is released, muscle tissue is repaired, and the immune system consolidates its activity. A night with adequate total sleep time but suppressed slow-wave sleep leaves you less recovered than an equivalent-length night without that suppression.

The next-day symptoms of caffeine-disrupted sleep quality include:

Waking feeling unrested despite adequate hours
Relying on caffeine immediately upon waking to function
Afternoon fatigue that seems disproportionate to the night
Reduced cognitive sharpness that improves when caffeine wears off the next evening

Research from Matthew Walker's lab at UC Berkeley and published work by other sleep scientists has consistently demonstrated this slow-wave suppression effect at caffeine doses that do not prevent sleep onset. The National Sleep Foundation includes caffeine-sleep timing guidance in their clinical resources.

Calculating Your Personal Cut-Off Time

A cut-off time based on half-life gives you a more defensible target than a rule of thumb. The calculation requires:

Your sleep time
Caffeine's half-life for you personally (population average: 5-6 hours; slower for slow metabolizers, certain medications, liver conditions; faster for fast metabolizers)
How much caffeine you want remaining at sleep time (goal: less than ~25mg for minimal sleep impact)

Working backwards from a target residual:

Target: < 25mg at sleep time
Caffeine dose: 100mg (small cup of coffee)

Half-lives needed to reach 25mg from 100mg = 2
(100mg → 50mg after 1 half-life → 25mg after 2 half-lives)

At 5.5-hour half-life: 2 × 5.5 = 11 hours before sleep

Sleep at 11pm → consume no more caffeine after 12pm noon
Sleep at 11pm with 200mg dose → consume after 9am cutoff for 2 half-lives, or cut off after 12pm for 75mg residual (still moderate)

The math shifts significantly if you are a slow metabolizer. Oral contraceptive users averaging a 10-11 hour caffeine half-life need roughly twice the clearance window for the same residual target.

Variables That Shift Individual Half-Life

Genetic CYP1A2 activity. Fast metabolizers clear caffeine in as little as 3-4 hours. Slow metabolizers average 6-8 hours without other modifying factors. Testing is available (23andMe includes CYP1A2 variants) but most people work this out empirically by observing whether afternoon caffeine predictably disrupts their sleep.

Pregnancy. Caffeine half-life extends progressively through pregnancy. By the third trimester, caffeine clearance is roughly three times slower than normal - a half-life of 15 or more hours. This is a primary reason for the lower caffeine limit during pregnancy and means that even morning caffeine has meaningful residual concentration at bedtime.

Oral contraceptives. As discussed above, estrogen-based contraceptives roughly double caffeine half-life for most users.

Liver disease and alcohol. The liver processes caffeine, and impaired liver function substantially slows clearance.

Age. Newborns and infants clear caffeine extremely slowly (one reason caffeine-containing beverages are not appropriate for young children). In adults, age has a modest effect on clearance, generally slowing it slightly.

Smoking. Counterintuitively, smoking accelerates caffeine metabolism. Smokers typically have half-lives of 3-4 hours. This is why some smokers find they need more caffeine to get the same effect and why quitting smoking sometimes makes caffeine feel suddenly more potent.

The National Institutes of Health publishes pharmacokinetic research on caffeine that covers these variables in detail. The American Academy of Sleep Medicine maintains clinical guidance on caffeine and sleep timing.

A Practical Approach to Timing

Rather than applying a single rule (no caffeine after 2pm), calculate a cut-off based on your actual sleep time and your best estimate of your half-life:

Decide what time you need to be asleep by for adequate rest.
Work back two half-lives for a target of ~25% of your dose remaining.
Work back three half-lives for a target of ~12.5% remaining (more conservative, appropriate for slow metabolizers or caffeine-sensitive individuals).
Treat the result as your last significant caffeine consumption time.

For most adults sleeping at 11pm with a standard 5.5-hour half-life, this places the cut-off around noon to 2pm for moderate doses. For slow metabolizers or those on oral contraceptives, the cut-off shifts to mid-morning.

This free calculator at EvvyTools includes a half-life timeline that shows estimated caffeine clearance throughout the day based on your intake log. You can use it to see exactly when your daily caffeine is projected to fall below a residual threshold for your sleep time. The Caffeine Calculator is at evvytools.com/tools/health-fitness/caffeine-calculator/.

For the full framework on body-weight-based daily limits alongside timing, see the article at evvytools.com/blog/how-much-caffeine-is-safe-per-day-body-weight-guide/.

The Takeaway

Half-life is the mechanism that explains why "no coffee after 2pm" sometimes works and sometimes does not. The rule is calibrated for an average person with an average half-life and an average sleep time. For people who sleep later, metabolize caffeine slower, or take medications that extend half-life, the actual safe cut-off is earlier.

The cut-off time that protects your sleep quality is not a fixed number. It is a calculation - one that accounts for your specific dose, your specific half-life estimate, and your specific sleep schedule. Applied consistently, it removes one of the most common causes of chronically degraded sleep quality that appears to have no obvious cause. The combination of a weight-based daily limit and a half-life-derived cut-off time gives you the two controls that matter most for managing caffeine without eliminating its benefits.

7 Free Caffeine and Sleep Tracking Tools Worth Using Together

EvvyTools — Mon, 25 May 2026 10:53:04 +0000

Managing caffeine effectively requires two things: knowing how much you consume and understanding what it does to your sleep. The tools that track food and beverage intake generally do not include sleep analysis. The tools that track sleep do not always highlight caffeine timing as a variable. Using both categories together closes the gap.

These seven tools cover caffeine tracking, sleep analysis, and the research context that connects them. All have substantial free tiers or are entirely free to use.

1. EvvyTools Caffeine Calculator

Before adjusting anything, you need a baseline number calculated for your body weight rather than a generic guideline. The Caffeine Calculator at EvvyTools calculates a weight-based daily caffeine limit using the 3-6mg/kg framework supported by research, then allows you to log beverages throughout the day to track intake against that limit.

The calculator also includes a half-life timeline that estimates when your daily caffeine will clear to a safe residual for sleep. This is the piece most tracking apps miss: not just how much you consumed but when that caffeine will stop affecting you.

For a full explanation of how to interpret the results and apply timing to your schedule, the guide at evvytools.com/blog/how-much-caffeine-is-safe-per-day-body-weight-guide/ covers the calculation methodology and common use cases in depth.

2. Cronometer

Cronometer is a food and nutrient logging app that includes caffeine as a tracked nutrient alongside standard macros and over 80 micronutrients. Because its database relies heavily on verified USDA data rather than user-submitted entries, caffeine figures for specific foods and beverages are generally more accurate than in apps that rely on crowdsourced entries.

Cronometer's caffeine tracking works as part of its broader food logging system. You log meals and beverages, and the daily nutrient summary includes your total caffeine intake. It does not provide a body-weight-based limit or half-life analysis, but it is a reliable data source for tracking the actual caffeine in what you eat and drink, including caffeine from chocolate, tea, and non-obvious sources that many people miss.

The free tier includes full nutrient tracking. Cronometer is particularly useful for people already tracking macros or micronutrients who want caffeine included without adding a separate app.

3. Sleep Cycle

Sleep Cycle is a sleep tracking app that analyzes sleep quality using phone microphone or accelerometer data. It produces a nightly sleep quality score and tracks patterns over time, including sleep phase distribution (light, deep, and REM sleep).

The free tier includes basic sleep quality tracking and smart alarm functionality that wakes you during a light sleep phase within a configurable window. The premium tier adds detailed sleep stage analysis and long-term trend tracking.

Sleep Cycle is relevant to caffeine management because it provides the feedback loop that makes caffeine timing adjustments legible. Tracking whether your sleep quality score changes when you adjust your afternoon caffeine cut-off time turns subjective impression into observable data. It does not tell you why your sleep quality changes, but combined with caffeine tracking, the pattern becomes visible.

4. Garmin Connect (with a Garmin device)

Garmin Connect is the companion platform for Garmin wearables, which use wrist-based accelerometers and pulse oximetry to estimate sleep stages. If you already own a Garmin watch, the app provides free sleep analysis including Body Battery score (an energy level metric that incorporates sleep quality), stress tracking throughout the day, and HRV (heart rate variability) scores that correlate with sleep quality and physiological recovery.

HRV in the morning is a sensitive marker of sleep quality and recovery status. Caffeine's suppression of slow-wave sleep shows up as reduced morning HRV over time, even when total sleep time is adequate. Tracking morning HRV alongside afternoon caffeine timing provides a more physiologically grounded feedback signal than subjective sleep quality alone.

The app is free; you need a compatible Garmin device to use the sleep features.

5. USDA FoodData Central

FoodData Central is the USDA's official food composition database. It is not a tracking app, but it is the most authoritative freely available reference for caffeine content in specific foods and beverages.

When you want to verify the caffeine content of a specific coffee brand, tea type, or food product before trusting an app entry, FoodData Central is the primary upstream source. Many food logging apps draw from this database for their core entries.

Searching for "caffeine" in FoodData Central returns hundreds of food entries with their measured caffeine content per serving. This is useful when tracking products not in standard databases, verifying suspiciously high or low figures, or researching the caffeine in less common sources like yerba mate, guayusa, or specific tea preparations.

6. National Sleep Foundation Sleep Diary

The National Sleep Foundation offers a free printable sleep diary format that tracks bedtime, wake time, sleep quality rating, and factors that may have affected sleep - including caffeine consumption.

A paper-based diary sounds low-tech compared to wearables, but it has a significant advantage: it forces daily deliberate reflection rather than passive data collection. Completing a sleep diary entry takes two minutes and requires you to attribute the previous night's sleep quality to specific behaviors, which builds the habit of connecting caffeine timing and intake to sleep outcomes in a way that reviewing an app passively does not.

The NSF diary format is designed for clinical sleep assessment but works equally well for personal tracking. It is available free to download from their website.

7. Caffeine Informer

Caffeine Informer is a reference database focused specifically on caffeine content across thousands of beverages, supplements, and foods. It is not a tracking tool but a lookup resource, and it is particularly useful for energy drinks, pre-workout supplements, and branded coffee products where caffeine content varies significantly by product.

The site also includes safe caffeine calculators (separate from the EvvyTools calculator), a caffeine sensitivity quiz, and research summaries on caffeine's health effects. For someone trying to track caffeine accurately across products with wide variation in caffeine content, Caffeine Informer is the most comprehensive free reference available.

Photo by Patrick on Pexels

How These Tools Work Together

The most effective approach combines active tracking with feedback:

Use the EvvyTools Caffeine Calculator to establish your weight-based daily limit and track intake by beverage.
Use Cronometer if you are already food logging and want caffeine included without a separate app.
Use Caffeine Informer to look up caffeine content for specific products not in your main tracking app.
Use Sleep Cycle or Garmin Connect to track sleep quality and HRV as feedback signals when you adjust caffeine timing.
Use FoodData Central to verify nutrient data for unusual sources.
Use the NSF Sleep Diary during an intentional caffeine timing experiment to capture the relationship between behavioral changes and sleep outcomes.

The combination closes the feedback loop that using any single tool leaves open. Caffeine tracking without sleep feedback tells you how much you consumed but not what it did. Sleep tracking without caffeine data produces unexplained variation in sleep quality that the data alone cannot diagnose.

This free caffeine resource at EvvyTools provides the weight-based limit and timing analysis that most tracking apps skip. The National Institutes of Health and American Academy of Sleep Medicine both publish research and guidance on caffeine and sleep timing for additional context on the science behind the tools.

How Biweekly Mortgage Payments Eliminate Years of Interest

EvvyTools — Sun, 24 May 2026 11:29:10 +0000

Switching from monthly to biweekly mortgage payments is one of the simplest ways to make a meaningful dent in your loan without budgeting for a large extra payment. The mechanism is a calendar quirk, not financial engineering, and it produces real, calculable savings with no change to your monthly cash flow pattern.

How the Math Works

A monthly payment schedule produces 12 payments per year. A biweekly schedule -- paying half your monthly amount every two weeks -- produces 26 half-payments per year. That equals 13 full payments instead of 12.

The thirteenth payment goes entirely to principal. On a $300,000 mortgage at 7% for 30 years, one extra full payment per year applied to principal cuts approximately 4 to 5 years off the loan term and saves somewhere between $65,000 and $75,000 in total interest depending on exactly when during the year the extra payments fall.

The reason the savings are so large is the front-loading effect in mortgage amortization. In the early years of a 30-year loan, most of your payment covers interest. Extra principal payments eliminate that balance and all the future interest that would have been calculated on it. A dollar applied to principal in year two of the loan saves more than a dollar applied in year twenty, because the earlier payment eliminates more compounding periods of interest.

The Calendar Mechanism

There are exactly 52 weeks in a year. Divide that by 2 and you get 26 biweekly payment periods. Each biweekly period, you pay half your monthly payment. Over the course of the year, you have made 26 half-payments, which equals 13 full monthly payments. The extra full payment happens because the year contains a fractional number of months (4.33 weeks per month on average), not because you are paying more each period than you can afford.

This is why biweekly payments work without changing your weekly budget significantly. You simply shift from paying $1,996 once a month to paying $998 every two weeks. The cash outflow is essentially identical from a budgeting perspective, but you end up with one more full payment applied to principal each year.

Setting Up Biweekly Payments Correctly

Not all mortgage servicers offer a true biweekly program, and some that do charge a setup fee. Before enrolling in anything, ask your servicer exactly how they handle biweekly payments. Some programs collect payments biweekly but only apply them to the loan monthly -- which gives you no advantage over standard monthly payments.

The correct setup for maximum benefit is one where each biweekly payment is applied to the loan immediately upon receipt, reducing the balance and the interest charge for the remainder of the month. If your servicer bundles them and applies monthly, the biweekly program is cosmetically different from monthly payments but functionally identical.

If your servicer does not offer a true biweekly program, replicate the effect manually. Divide your monthly payment by 12 and add that amount to each monthly check, labeled as extra principal. On a $1,996 monthly payment, that is about $166 per month extra. Over 12 months, you have added roughly $2,000 to principal -- approximately one full extra payment.

Photo by David Todd McCarty on Unsplash:** Loan pays off in approximately 25 to 26 years. Total interest paid: roughly $345,000 to $355,000. Interest savings: approximately $65,000 to $75,000.

The payoff date moves up by four to five years. The total interest reduction is real and significant. For a $400,000 loan at 7%, the same biweekly approach saves proportionally more -- roughly $90,000 to $100,000 in total interest.

The exact figures for your loan depend on your starting balance, rate, remaining term, and the timing of extra payments within the year. You can run these scenarios with your specific numbers using the free mortgage payment calculator by EvvyTools, which generates a full amortization table with an extra annual payment field.

When Biweekly Payments Make Less Sense

If you are early in your career and tight on cash flow: The biweekly structure commits you to a slightly higher payment frequency. If your income is irregular or your cash flow does not support two fixed withdrawals per month, missing a payment creates complications that outweigh the interest savings.

If your servicer charges a setup fee: Some biweekly programs charge $200 to $400 to enroll. At $65,000 to $75,000 in total savings, a one-time fee is a minor factor, but you should know about it before signing up. The manual method (adding 1/12 of your payment to each monthly check as principal) achieves the same result with no enrollment cost.

If you have higher-rate debt: Credit card debt at 20%, personal loans at 12%, or car loans at 8% all cost more than a 7% mortgage. Pay those down first. The interest savings from eliminating high-rate consumer debt exceed what biweekly mortgage payments produce on a dollar-for-dollar basis.

Comparing Biweekly to Other Extra Payment Strategies

Biweekly payments are a specific version of the broader extra payment strategy. The comparison is:

Monthly extra payment: You add a fixed amount each month. More flexible, can be adjusted or stopped if cash flow changes. Allows you to optimize the timing and amount continuously.

Biweekly payments: Automates the extra payment through the calendar mechanism. Less flexible once enrolled in a program, but requires no conscious decision each month. Good for people who want to set it and forget it.

Annual lump sum: Apply a tax refund or bonus to principal once a year. The timing matters -- earlier in the calendar year is generally better. Less consistent than monthly or biweekly but can be larger in a good income year.

For most borrowers, the biweekly approach is appealing because it requires no ongoing decisions and no perceived change in monthly budget. The calendar does the work.

covers the compounding math behind front-loaded amortization.

The Consumer Financial Protection Bureau has guidance on biweekly payment programs and what to watch for with servicers that charge fees or bundle payments. Freddie Mac publishes research on mortgage equity accumulation patterns that show how different payment strategies affect typical borrower equity over time. Before deciding between biweekly payments and a refinance, check current average rates at Bankrate -- if rates have dropped significantly since you closed, a rate reduction may save more in total interest than the extra thirteenth payment the biweekly schedule provides.

The Bottom Line

Biweekly mortgage payments work because 52 weeks divided by 2 is 26, not 24. That extra two half-payments per year translate into one additional full principal payment. Over a 30-year loan, that single extra payment per year eliminates four to five years of remaining debt and saves tens of thousands in interest. It requires no change to your income and no special financial discipline -- just a payment schedule that lets the calendar work for you.

Visit EvvyTools for mortgage calculators that let you model biweekly schedules, extra payments, and full amortization tables for your specific loan.

How to Calculate the Interest Savings from Extra Mortgage Payments

EvvyTools — Sun, 24 May 2026 11:29:08 +0000

Extra mortgage payments save money because they reduce principal, and reduced principal means less interest accrues on every future payment. The savings are real, but most people do not know how to calculate them without a financial calculator or spreadsheet. This guide walks through the process step by step.

What You Need Before You Start

You need four numbers to calculate your interest savings:

Current outstanding loan balance -- not the original loan amount, the balance you owe right now
Annual interest rate -- your current mortgage rate, not an APR with fees included
Remaining term in months -- count from your next payment date, not from origination
Extra payment amount -- the additional principal you plan to add per month, year, or as a one-time lump sum

Your servicer's monthly statement or online account portal will show your current balance and remaining term. Your interest rate is on your original loan documents and the servicer's portal.

Step 1: Calculate Your Current Monthly Payment

If you do not already know your required monthly payment, calculate it from your remaining balance, rate, and term. The formula uses the standard mortgage payment equation:

M = P * [r(1+r)^n] / [(1+r)^n - 1]

Where:

M = monthly payment
P = outstanding principal balance
r = monthly interest rate (annual rate divided by 12)
n = remaining months on the loan

For a $250,000 balance at 7% annual interest with 300 months (25 years) remaining:

Monthly rate r = 0.07 / 12 = 0.005833
M = 250,000 * [0.005833 * (1.005833)^300] / [(1.005833)^300 - 1]
(1.005833)^300 = approximately 5.656
M = 250,000 * [0.005833 * 5.656] / [5.656 - 1]
M = 250,000 * [0.032985] / [4.656]
M = 250,000 * 0.007085
M = approximately $1,771 per month

Step 2: Calculate Total Interest Without Extra Payments

Multiply your monthly payment by the number of remaining months, then subtract your current balance:

Total interest (no extra payments) = (M * n) - P

Using the example: ($1,771 * 300) - $250,000 = $531,300 - $250,000 = $281,300 in total interest

Step 3: Calculate Total Interest With Extra Payments

This step requires finding how many months your loan will last if you add the extra payment to each required payment. This calculation is iterative -- you cannot solve it with a single formula -- but you can approximate it or use a tool.

The approximation method: For a monthly extra payment of $200 on the example loan:

Your effective monthly payment becomes $1,771 + $200 = $1,971. Now solve for n using the same formula rearranged, or use an online calculator. With $1,971 per month applied to a $250,000 balance at 7%, the loan pays off in approximately 243 months instead of 300.

Total interest (with extra payments) = ($1,971 * 243) - $250,000 = $478,953 - $250,000 = $228,953 in total interest

Interest savings: $281,300 - $228,953 = $52,347 saved

That is $52,347 saved by adding $200 per month. The total extra amount paid over 243 months is $200 * 243 = $48,600. The savings exceed the extra payments by over $3,700 -- plus you own the home free and clear 57 months earlier.

Step 4: Verify With an Amortization Table

The calculation above gives you a good approximation, but rounding errors accumulate over hundreds of months. For an exact figure, use an amortization table or a dedicated mortgage calculator.

generates a full month-by-month amortization schedule for any loan. Enter your current balance, rate, remaining term, and extra payment amount, and the tool shows exact interest savings, the new payoff date, and the month-by-month balance for both the original and accelerated schedules.

Step 5: Calculate the Savings on a One-Time Lump Sum

Extra payments do not have to be monthly. A one-time lump sum applied to principal saves the interest that would have accrued on that amount for every remaining month.

Formula for lump-sum savings:

Lump-sum interest savings = L * r * (1 - (1+r)^-(n-1)) / (1 - (1+r)^-n)

This gives the approximate interest eliminated. A simpler way to think about it: multiply the lump sum by your monthly rate (0.005833 for 7%) and then by the approximate number of remaining months affected.

For a $10,000 lump sum on a 25-year remaining loan at 7%:
$10,000 * 0.005833 * 300 = $17,499 in approximate interest eliminated

The actual savings are slightly different because as the balance falls, the monthly interest charge also falls, which is why an amortization table gives a more accurate figure.

Step 6: Compare Strategies

Once you can calculate interest savings for a given extra payment amount, you can compare strategies:

$100/month extra vs. $1,200 lump sum in January: Both apply the same annual cash outflow. The monthly approach saves slightly more because it reduces the balance throughout the year rather than all at once at the start of January. The difference is small but real.

Early extra payments vs. late extra payments: A $5,000 lump sum applied at year 5 saves more than the same $5,000 at year 15. On a 30-year loan at 7%, the difference can be $5,000 to $8,000 in additional interest savings depending on how many remaining years the balance reduction affects.

Monthly extra payment vs. refinancing: If you can refinance to a significantly lower rate, the total interest reduction may exceed what extra payments on the higher-rate loan would achieve. The Consumer Financial Protection Bureau provides refinancing guidance that includes a break-even calculator for closing costs versus monthly savings.

covers the compounding mechanics behind why early payments save more and how to think about the opportunity cost against investing the same dollars.

Bankrate provides a mortgage payoff calculator alongside their rate comparison tools that handles the iterative calculation automatically. Freddie Mac offers economic research on how prepayments affect loan portfolios, which provides useful background on how servicers and lenders think about the same math.

Run your own numbers in the free mortgage payment calculator by EvvyTools, then revisit EvvyTools for related tools on home buying, refinancing, and personal finance planning. The mortgage calculator generates a full amortization table for any extra payment scenario, which makes it easy to verify your manual calculations and see exactly how the payoff date and total interest change month by month when you add even a modest extra payment each month.

How Lumber Density Affects Your Woodworking Project Budget

EvvyTools — Sat, 23 May 2026 13:03:39 +0000

Woodworkers typically plan projects around looks and workability. The species that looks right and cuts well gets chosen. But density - how much a wood actually weighs per cubic foot - has a direct and underestimated impact on project costs that goes well beyond the board foot price tag.

Understanding density before you commit to a species can prevent budget surprises, shipping headaches, and decisions that cause problems mid-build.

What Lumber Density Actually Measures

Wood density is the mass of a piece of wood per unit of volume. For woodworkers, the most useful way to think about it is pounds per cubic foot of dried lumber. This number varies significantly across species - from around 20 lbs per cubic foot for very light softwoods to over 60 lbs per cubic foot for tropical hardwoods.

Density is different from hardness. The Janka hardness test measures resistance to surface denting and wear, which matters for flooring and tabletops. Density measures overall mass, which matters for structural applications, shipping, and how heavy the finished piece will be.

A coffee table built from hard maple will weigh roughly 30-40% more than the same table built from poplar. If the piece needs to be moved regularly, that matters. If it's a permanent installation, it may not.

The Budget Impact of Density

The obvious cost component is price per board foot. Dense hardwoods like walnut, maple, and cherry cost more per board foot than softwoods or less dense hardwoods. But the budget impact extends into several areas that are less obvious.

Shipping and delivery. If you're ordering lumber from a hardwood dealer by mail or carrier freight, weight determines cost. A 100-board-foot order of Eastern White Pine (roughly 25 lbs per cubic foot) might weigh around 130 lbs. The same order in Hard Maple (roughly 44 lbs per cubic foot) would weigh over 220 lbs. At freight rates, that difference adds meaningfully to delivered cost.

Tooling and consumables. Dense hardwoods dull blades, bits, and sandpaper faster than softwoods or lower-density hardwoods. A table saw blade that lasts through 200 board feet of pine might need sharpening after 60-80 board feet of hard maple. This isn't a large cost per project, but it adds up across a woodworking shop's output.

Finishing. Dense, close-grained species (cherry, walnut, hard maple) often require less sanding and finishing labor because the grain is tighter and takes fewer coats. Porous open-grained species like oak and ash require grain filler before topcoating if you want a smooth surface. Time spent on finishing is a real cost.

Structural implications. For tables, shelves, and storage pieces, dense wood means heavier structural members are needed to support the weight of the wood itself in addition to the load. A shelf built from heavy tropical hardwood may need stronger supports than the same shelf in pine, adding hardware and joinery cost.

Photo by Tuherdias Awang on Pexels

Common Species Comparison by Density

The Wood Database maintains comprehensive density data for hundreds of species. Per the lumber overview on Wikipedia, density varies even within a species based on growth conditions and moisture content, so published figures are useful baselines rather than exact per-board values. A practical comparison of commonly available domestic species:

Species	Density (lbs/cu ft)	Janka Hardness	Common Use
Eastern White Pine	25	380	Painted furniture, shelving, trim
Poplar	28	540	Painted furniture, drawer boxes
Soft Maple	34	700	Furniture, cabinets
Black Cherry	35	950	Fine furniture, cabinets
Black Walnut	38	1010	Fine furniture, gun stocks
Red Oak	44	1290	Furniture, flooring
Hard Maple	44	1450	Workbench tops, flooring
White Ash	41	1320	Tool handles, sports equipment

The data above comes directly from the Wood Database, which cross-references multiple measurement sources per species. Numbers vary slightly by measurement method and sample source.

For budget planning, the practical takeaway is that doubling the density number roughly doubles the shipping weight and increases tooling wear proportionally.

Calculating Weight Before You Order

Knowing density lets you calculate the total weight of a lumber order before you commit to buying. The formula:

Weight = (Board Feet x Thickness in inches x Density in lbs per cubic foot) / 12

For a 50-board-foot order of Red Oak at 44 lbs per cubic foot:
Weight = (50 x 1 x 44) / 12 = approximately 183 lbs

For the same order in Poplar at 28 lbs per cubic foot:
Weight = (50 x 1 x 28) / 12 = approximately 117 lbs

The free board foot calculator by EvvyTools includes weight output alongside board feet and cost estimates for over 30 species. Running both species through the calculator before ordering shows the weight and cost difference side by side.

The full lumber quantity guide at How to Calculate Lumber Quantities for Any Woodworking Project walks through how density figures into a complete project materials estimate.

When to Choose Dense vs Light Species

Dense species are worth the premium when:

The piece will be used hard (workbench tops, tool handles, flooring, cutting boards)
Visual figure or color justifies the cost (walnut, cherry)
Long-term durability matters more than initial cost

Lighter species are the better choice when:

The piece will be painted (density doesn't affect appearance under paint)
Weight of the finished piece is a practical concern
The project is a prototype, jig, or shop furniture where appearance is secondary
Budget limits apply and the application doesn't require hardwood properties

For most beginners and most painted projects, poplar is the practical choice: cheap, easy to work, readily available at home centers and hardwood dealers, and stable enough for furniture. The difference in hardness between poplar (540 Janka) and oak (1290 Janka) matters for a dining table that will get daily hard use, but not for a painted cabinet where finish durability depends on the topcoat, not the wood underneath.

Using Species Data Before You Design

The most expensive mistake is designing a piece, buying materials, and discovering that the weight is impractical or the tooling cost exceeds the budget for that wood choice. Running density calculations before finalizing the design prevents this.

A few practical checks before committing to a species:

First, calculate the total weight of the finished piece. A cabinet built from hard maple at 44 lbs per cubic foot might be impractical to move for installation or to carry up stairs. The same design in soft maple (34 lbs per cubic foot) is meaningfully lighter.

Second, check availability. Exotic and less common domestic species aren't always in stock at local dealers. If your project is time-sensitive, designing around readily available species (red oak, hard maple, poplar, pine) is safer than committing to a species that requires a special order.

Third, consider the grain. Dense, close-grained species like hard maple can be challenging for hand tool work and require sharp, well-tuned machinery. Open-grained species like oak are more forgiving of tool condition but require extra finishing steps. These choices affect both the enjoyment of the project and the time budget.

Photo by Pew Nguyen on Pexels

The Relationship Between Density and Cost Per Pound

One way to compare species value is cost per pound of finished lumber rather than cost per board foot. Because denser species weigh more per board foot, a cheaper-per-board-foot option can cost more per pound of actual wood.

This calculation rarely changes the final decision - you're buying wood to make something, not to maximize mass per dollar. But it does illustrate why price per board foot alone doesn't capture the full cost picture. Factor in the total weight of your order, the delivered cost, and the additional tooling and finishing expenses to get an accurate project budget before starting.

The Board Foot Calculator at EvvyTools outputs both board feet and weight per species, giving you both numbers in one place for project budget comparisons.

How to Build a Cut List Before Buying Lumber

EvvyTools — Sat, 23 May 2026 13:03:37 +0000

A cut list is a simple table: every piece your project needs, with dimensions. It takes 20-30 minutes to build for most furniture projects, and it's the difference between accurate lumber purchasing and guessing at the lumberyard.

This guide walks through building a cut list from scratch, converting it to board feet, and using it to generate a total materials estimate before you buy anything.

Why Cut Lists Exist

Woodworking projects fail in two predictable ways: you run out of a specific piece mid-build because you forgot to account for it, or you buy excess material that gets stacked in the shop and never used.

A cut list prevents both. By documenting every piece before ordering, you account for everything the project requires. By converting dimensions to board feet, you translate a design into a purchase quantity. The output is a single number: how much lumber to buy.

The process isn't complicated. It just requires doing it before driving to the lumberyard.

Step 1: Finalize Your Design Dimensions

Before making a cut list, your design needs to be dimensionally complete. Approximate dimensions produce approximate cut lists. Approximate cut lists produce wrong quantities.

You don't need CAD software. A dimensioned sketch on paper works fine. What you need is the finished size of every part: length, width, and thickness in actual dimensions (what the piece will be in the finished project, not the stock size you'll buy).

For furniture with joinery - drawers, doors, frames - work out the joinery before finalizing part dimensions. A mortise-and-tenon joint adds length to the tenon piece. Drawer sides fit inside the case, so their width relates to the case interior dimension. Getting these relationships right in the design means your cut list is correct.

If you're working from published plans, the cut list is usually included. Verify the dimensions against the drawing before using it - errors in plans exist, and a wrong part dimension is easier to catch on paper than after cutting.

Step 2: List Every Part

Open a spreadsheet or get a piece of paper. Column headers: Part Name, Quantity, Thickness, Width, Length, Material. A row for each unique piece.

Start with the largest structural parts and work down to the smallest. For a simple wall cabinet:

Cabinet sides (2 pcs)
Cabinet top/bottom (2 pcs)
Back panel (1 pc)
Fixed shelf (1 pc)
Door (1 pc)
Face frame stiles (2 pcs)
Face frame rails (2 pcs)

List parts that are cut from different materials in separate rows. Solid wood parts go on different rows than plywood parts. Different species go on separate rows.

Step 3: Specify Finished Dimensions

For each row, record the finished dimensions - the size the part will be after all milling, joinery, and fitting is done.

For solid wood parts, this means:

Thickness: what the piece will be after final planing. If you're buying 4/4 (1" nominal) lumber and surfacing to 3/4", record 0.75".
Width: what the piece will be after jointing and ripping to final width.
Length: what the piece will be after crosscutting to final length.

For sheet goods (plywood, MDF):

Thickness: the sheet thickness (3/4", 1/2", etc.) as purchased
Width and Length: the cut dimensions, not the full sheet size

These finished dimensions are what you'll actually produce. Don't use nominal lumber dimensions here.

Step 4: Account for Grain Direction

For furniture where wood movement matters - tabletops, drawer fronts, cabinet doors - note the grain direction for each piece. This affects how parts are cut from boards.

A wide tabletop built from narrow edge-glued boards should have grain running the same direction across the width for consistent expansion and contraction. If you need six 6-inch wide pieces from 8/4 stock for table legs, the boards need to be oriented correctly relative to the grain.

Noting grain requirements on the cut list helps when selecting and laying out boards at the lumberyard or hardwood dealer. It also affects your waste calculation - you can't nest pieces oriented arbitrarily when grain direction is constrained.

Step 5: Convert to Board Feet

With your cut list complete, convert each row to board feet:

Board Feet = (Thickness x Width x Length in feet) / 12

For 2 pieces at 0.75" x 5.5" x 36" (3 feet):
(0.75 x 5.5 x 3) / 12 x 2 pieces = 2.06 board feet

Do this for each row of solid wood parts. Add the board foot totals.

The Board Foot Calculator at EvvyTools handles this calculation for each piece and provides totals. The related lumber quantity guide at How to Calculate Lumber Quantities for Any Woodworking Project covers the formula in detail if you're doing it manually.

For sheet goods, convert to square feet and the number of full sheets needed instead.

Photo by AI25.Studio Studio on Pexels

Step 6: Add Waste Factors

Raw board feet from the cut list is the finished material requirement. You need more than that.

Waste comes from multiple sources:

Saw kerf: Each cut removes roughly 1/8" of material. Across many cuts, this adds up.
Defects: Knots, checks, sap, and grain irregularities reduce yield. Budget defect waste by species and grade.
Grain matching: Cuts can't always be nested optimally when grain must be continuous across pieces.
Milling: Surfacing and jointing removes material. Rough-sawn lumber loses 20-25% to surfacing.
Error: Cuts go wrong. Parts get miscut and must be remade.

Practical waste factors by project type:

Simple dimensional construction (shelving, shop furniture): add 10%
Mixed-width furniture (tables, case pieces): add 15%
Complex joinery or grain matching required: add 20%
Rough-sawn lumber (add on top of other factors): add 20-25% for surfacing loss

Apply the relevant factor to your board foot subtotal for each material. This is your purchasing quantity.

Step 7: Check Species and Grade Availability

Before finalizing your cut list, verify that your chosen species is available in the dimensions you need.

Wide boards (10" and up) in premium hardwoods require clear lumber grades. FAS and Select grades at a hardwood dealer typically provide 6-9 inch clear sections reliably; wider boards cost more per board foot because they're scarcer. If your design calls for 12-inch wide boards in walnut, budget for the premium or adjust the design to use edge-glued narrower boards.

Long lengths also affect cost. 8-foot boards are standard. 10 and 12 foot lengths are available at most dealers but cost more per board foot. If your cut list has several long pieces, factor this in.

For context on how cut lists fit into woodworking practice more broadly, the Wikipedia overview covers the full workflow from design to finishing. Woodcraft and Rockler both publish retail pricing online for common hardwoods, which gives a reference for species availability and approximate cost before visiting a local dealer.

Step 8: Separate by Material

If your project uses multiple species or mixes solid wood and plywood, create separate totals for each material. You'll buy these from different sources and at different times.

A typical furniture project might require:

X board feet of 4/4 soft maple for face frames
Y board feet of 8/4 hard maple for legs
Z sheets of 3/4 maple plywood for case panels
W board feet of 1/2" birch plywood for drawer bottoms

Keeping materials separate means you can source them independently and verify pricing before committing.

Photo by Magda Ehlers on Pexels

The Completed Cut List in Use

With a complete cut list in hand, a lumberyard visit changes. Instead of walking around guessing at quantities, you have a specific list: 22 board feet of 4/4 red oak, 8 board feet of 8/4 red oak, 1 sheet of 3/4 red oak plywood.

You can verify prices before driving out. You can call ahead if a less common species requires advance notice. You can confirm availability of specific dimensions.

The EvvyTools board foot calculator is particularly useful in this step because it outputs both board feet and weight, letting you verify you can physically handle the lumber you're ordering.

Most importantly, a cut list makes waste visible before you spend money on it. Seeing that your waste factor adds 3 board feet to an order gives you the opportunity to adjust the design to use that waste productively rather than throwing it away.

The 20 minutes spent building a cut list is time bought back at the lumberyard, during the build, and at project completion.

Why Negative Splits Are the Pacing Goal Every Runner Should Train For

EvvyTools — Fri, 22 May 2026 11:28:00 +0000

If you have ever run a race and felt great in mile 3 but were hanging on for survival in mile 20, you ran a positive split. If you have ever crossed a finish line feeling like you had more to give, you probably ran a positive split of a different kind. The negative split -- finishing the second half of a race faster than the first -- is the pacing outcome that eliminates both of these failure modes.

It is also the outcome most runners never achieve because they do not train for it specifically.

The Basic Definition

A negative split means your second-half time is faster than your first-half time. In a marathon: miles 14-26.2 faster than miles 1-13.1. In a 10K: the back 5K faster than the opening 5K.

This sounds simple. In practice, it requires overriding several powerful instincts and environmental pressures that push you toward starting faster than you should.

Why It Matters Physiologically

The case for negative splits is not primarily psychological ("stay disciplined"). It is physiological:

Glycogen is finite: Running above your aerobic threshold depletes glycogen faster than fat metabolism can compensate. A marathon runner typically has 90-120 minutes of glycogen available at race effort. Going out 15-20 seconds per mile too fast in the first half means glycogen runs out earlier -- not by a little, but by enough to cause the wall.

Lactate accumulates non-linearly: Effort above your lactate threshold generates lactate (and the accompanying fatigue-producing hydrogen ions) faster than the body clears it. Running 5% too hard in the first miles does not produce 5% more fatigue -- it produces a compound effect that becomes apparent only in the second half.

Cardiovascular adaptation takes time: Heart rate and stroke volume take several miles to stabilize under race conditions. Runners who sprint from the gun are physiologically stressed before their cardiovascular system has reached its efficient operating point.

Photo by Jacob Lister Haugen on Pexels

What the Data Shows

Elite performances consistently validate the negative split approach. Championship marathon results from World Athletics sanctioned events show that world records and major podium finishes almost universally feature even or negative splits. The pattern holds from 5K championships down to the marathon.

For recreational runners, the data is equally clear. Analysis of road race results shows that personal records correlate strongly with even or negative splits. Runners who finish their best times are not the ones who went out fastest -- they are the ones who saved something for the end.

Runner's World has documented this pattern repeatedly in its analysis of marathon and half marathon results across all age groups. The most common finishing time correlates with the most common positive split pattern. The runners who outperform that average almost always did so by pacing more conservatively in the first half.

The Hard Part: Holding Back When It Feels Wrong

Knowing you should start conservatively is not the same as doing it. Race-day conditions work against you:

Adrenaline: Elevated pre-race adrenaline reduces perceived effort. The first mile at a pace that is ultimately unsustainable often feels completely manageable. By the time the physiological cost becomes apparent, you are already committed.

Crowd pressure: In a mass-participation event, the runners around you in the first mile are mostly going out too fast. Running with the crowd rather than your plan is the path of least resistance.

Fresh legs: At the start of any race, everything feels easy. The difference between goal pace and too-fast feels like nothing. It is not nothing.

The fix is pre-commitment: calculating your first-half target pace before race day, writing it on your arm or programming it into your watch, and treating that number as a ceiling rather than a floor for the opening miles.

Training the Habit

The negative split does not happen on race day by itself. It is a trained behavior:

Progression long runs: The weekly long run is the best place to practice negative splitting. Run the first half at an easy pace and the second half at goal marathon pace. This builds the physical and psychological pattern of conservative early pacing followed by a purposeful build.

Effort-based middle miles: During tempo runs, resist the urge to front-load effort. Starting at the bottom of the target effort range and building to the top trains the pattern of accelerating within a sustained effort, not decelerating.

Race simulations in tune-up events: Use shorter races (10K tune-ups before a marathon, 5K tune-ups before a half marathon) to deliberately practice negative split execution. Accept a slower opening mile than your ability warrants. Use the second half to confirm that you can hit goal pace when the race matters.

Calculating Your Targets

The standard differential for a negative split is 1-2% between first-half and second-half pace. For a 4:00 marathon goal (9:09 per mile average):

First half: 9:18-9:23 per mile (approximately 2:02-2:03 for 13.1 miles)
Second half: 8:55-9:00 per mile (approximately 1:57-1:58 for 13.1 miles)

The Pace & Race Time Calculator generates these targets automatically for any goal time and race distance. It also produces cumulative split times at key mile markers, which are the most useful format for race-day execution.

Photo by Matthew Edington on Pexels

The Numbers by Goal Time

Abstract advice to start conservatively is harder to act on than a specific target. Here is what the 1-2% negative split differential looks like for common marathon goal times:

Goal Time	Average Pace	First-Half Target	Second-Half Target
3:30	8:00/mi	8:09-8:14/mi	7:46-7:51/mi
4:00	9:09/mi	9:18-9:23/mi	8:55-9:00/mi
4:30	10:18/mi	10:29-10:34/mi	10:02-10:07/mi
5:00	11:27/mi	11:39-11:44/mi	11:10-11:15/mi

The first-half differential is consistent: 1-2% slower than average pace, which translates to roughly 9-14 seconds per mile for most recreational runners. The second-half targets are correspondingly 1-2% faster.

For half marathon, the same principle applies with smaller absolute values. A 2:00 half (9:09/mile average) targets a first half of approximately 9:18-9:23 and a second half of approximately 8:55-9:00.

These numbers belong on your arm before the race, not in your head during mile 2. Calculating them in advance and writing the first-half target on your wrist or programming it into your watch removes pacing decisions from a moment when adrenaline, crowd pressure, and fresh-leg confidence are all pushing you in the wrong direction.

The difference between executing a negative split and positive-splitting by 5 minutes in a marathon is almost never fitness. It is preparation and discipline in the opening miles.

The Payoff

The reward for a well-executed negative split is concrete: passing runners in the final miles instead of being passed by them, finishing with more in reserve than expected, and a finish line that arrives while you are still capable of running rather than jogging or walking.

More practically: a negative split is a faster race time. Every minute you give back in a second-half fade is a minute you do not have to give back in a well-paced race. The physiological math always favors starting conservatively.

For the complete strategy, specific first-half targets for your goal time, and race-day execution tips, read How to Run Negative Splits: The Pacing Strategy Behind Faster Race Times.

Using Race Prediction Formulas to Structure Your Training Cycle

EvvyTools — Fri, 22 May 2026 11:26:40 +0000

Most runners train by feel: run easy days easy, run hard days hard, do the long run on weekends. This is not wrong, but it leaves training intensity targets vague. Without specific pace zones derived from current fitness, hard days are often not hard enough to drive adaptation, and easy days are often not easy enough to enable recovery.

Race prediction formulas -- particularly Riegel's formula, which powers most online race predictors -- give you a data-based method for deriving specific training pace targets from a recent race effort. This article walks through how to use prediction outputs practically to set tempo, threshold, interval, and easy pace zones for an entire training block.

Step 1: Establish Your Current Fitness Baseline

The starting point is a recent time trial or race run at full effort. The input must reflect your genuine current fitness, not a training run or a race where you paced conservatively for other reasons.

Acceptable inputs:

A recent 5K race result
A recent 10K race result
A 1-mile or 2-mile time trial on a track
A half marathon run at full effort

Run within the past 4-6 weeks is ideal. Fitness changes enough over 8-12 weeks that older race results may generate training targets that are either too easy (if you have improved) or too aggressive (if fitness has declined due to injury or reduced training).

For detailed context on how the formula works and where its 1.06 fatigue exponent comes from, read Riegel's Formula Explained: How Race Time Prediction Actually Works.

Step 2: Generate Predicted Race Times

Using your recent race time, run the prediction formula for several distances:

For a 5K input of 25:00 (5:00/km, or about 8:02/mile), Riegel's formula gives:

Predicted 10K: approximately 52:04
Predicted half marathon: approximately 1:54:15
Predicted marathon: approximately 3:55:00

The Pace & Race Time Calculator -- use it here -- performs these calculations automatically and outputs the corresponding per-kilometer and per-mile paces for each distance.

These predicted times anchor your training zones.

Step 3: Derive Pace Zones from the Predictions

Classic training zone frameworks use percentages of threshold or VO2 max pace to define easy, moderate, tempo, and interval targets. Race predictions give you the reference points needed to calculate these zones.

Easy / recovery pace: 65-75% of effort, or approximately 75-90 seconds per mile slower than 5K race pace. For a 25:00 5K runner (8:02/mile average), easy pace is approximately 9:20-10:00 per mile.

Aerobic / general endurance pace: 75-80% effort, approximately 45-75 seconds per mile slower than 5K race pace. For the same runner: 8:47-9:17 per mile.

Marathon pace: The predicted marathon pace from the formula. For a 3:55 marathon prediction: approximately 8:58 per mile. This is the pace to practice in the later portions of long runs and in marathon-pace workouts.

Half marathon pace: Predicted half marathon pace. For a 1:54:15 prediction: approximately 8:43 per mile. This is the target for longer tempo runs of 40-60 minutes.

Tempo / lactate threshold pace: Approximately 10K to half marathon effort pace, around 85-90% intensity. For this runner: approximately 8:15-8:43 per mile.

Interval / VO2 max pace: 5K race pace or slightly faster. For this runner: 8:02 per mile or slightly faster. These are for shorter, intense repeats (400m-1200m) with recovery between.

Photo by Vladvictoria on Pixabay

Step 4: Structuring the Training Week

With pace zones derived, a structured training week might look like this for a marathon-focused block:

Monday: Rest or easy recovery run (9:20-10:00/mile)
Tuesday: Interval work at 5K-pace or faster (400m-800m repeats)
Wednesday: Easy run (9:20-10:00/mile) + strides
Thursday: Tempo run at half marathon pace (8:43/mile) for 30-40 minutes
Friday: Rest or easy run
Saturday: Long run with progression (easy first half, marathon pace second half: 8:58/mile)
Sunday: Easy recovery run (9:20-10:00/mile)

Every pace target in this week is derived from the single 5K baseline input. This is the advantage of prediction formulas: one recent race result produces a calibrated, internally consistent set of pace targets for the entire training block.

Step 5: Tracking Progress Across the Training Cycle

The other use of prediction formulas is tracking fitness change. Run a 5K time trial at the start of a training block, then run another one 8 weeks later. The change in predicted times at other distances tells you how your fitness has evolved.

If your 5K time trial drops from 25:00 to 24:15 over 8 weeks:

5K improvement: 45 seconds
Predicted marathon improvement: roughly 3-4 minutes (the formula translates a 5K improvement proportionally to longer distances)

This gives you a quantitative measure of training effect, which is more precise than comparing the feel of two long runs separated by weeks of different weather and fatigue levels.

Runner's World training plans and most structured marathon programs build in time trial assessments for exactly this purpose. Tracking the prediction trend across a cycle tells you whether training is working and whether your goal for the race is still realistic. Reviewing Strava activity data alongside time trial results provides additional context: average pace in long runs, heart rate trends, and training load all inform whether fitness gains are translating to improved predictions.

Step 6: Adjusting Goals as the Race Approaches

Race predictions are not fixed targets. They should be revisited as new race results or time trials come in.

If you started a 16-week marathon block with a 3:55 prediction from a 5K time trial and your 8-week 10K tune-up race produces a 3:48 prediction, your goal has improved. Revise the marathon goal and recalculate your pace plan accordingly.

If the tune-up produces a slower-than-expected time, investigate before downgrading the goal. One bad race under poor conditions is not necessarily a fitness measurement. Two bad results in a row warrant goal revision.

For predictions to be useful tools, they need to be treated as live inputs that get updated as new data comes in -- not as fixed commitments made at the start of a training cycle.

Photo by RyanMcGuire on Pixabay

Common Mistakes When Using Prediction Formulas

Using a slow input race: A 10K where you paced conservatively for a training run rather than racing hard produces a pessimistic prediction. Use only full-effort race results.

Ignoring training specificity: A 5K time from a track-focused runner predicts a marathon time that assumes full aerobic development at the marathon distance. If long run volume is low, adjust the prediction upward by 10-20 minutes.

Treating predictions as guarantees: The formula predicts what is physiologically possible given recent fitness. Race conditions, fueling, and execution determine where you actually land. The formula is a ceiling, not a floor.

Not updating predictions: Using a 4-month-old race result as the input during a training block where fitness has changed significantly gives you stale pace targets. Run a time trial or use a recent tune-up race every 6-8 weeks to keep your training zones calibrated.

The Practical Value of Data-Based Training

The alternative to data-based training is effort-based training calibrated by feel. Feel is valuable, especially for experienced runners with good self-awareness. But feel does not give you a number to write in a training log, share with a training partner, or compare across weeks. A prediction-derived pace zone does.

For the mathematical foundation behind race time predictions and why the 1.06 exponent was chosen, read the full breakdown at Riegel's Formula Explained: How Race Time Prediction Actually Works. To generate your own predictions and derive your training pace zones from a recent race result, visit the Pace & Race Time Calculator.

The data is already there in your last race result. This is how to use it.

Free Tools for Running Pace and Race Time Prediction

EvvyTools — Fri, 22 May 2026 11:26:36 +0000

Race day preparation involves a lot of arithmetic: converting goal times to per-mile paces, generating split targets at each mile marker, predicting marathon times from 5K results, and calculating the first-half pace for a negative split plan. Most runners do this with a phone calculator and some mental math. These tools do it better, for free.

1. EvvyTools Pace & Race Time Calculator

EvvyTools provides a pace and race time calculator that handles the core pacing calculations in one place: input your goal finish time and race distance, and it generates the per-mile pace, cumulative split times at key distance markers, and first-half and second-half split targets for a planned negative split.

The tool also runs race predictions using Riegel's formula -- enter a recent race result and it returns predicted finish times for 5K, 10K, half marathon, and full marathon distances, along with the corresponding target paces. This makes it useful both for planning a specific race and for deriving training pace zones from a recent time trial.

What makes it worth bookmarking: the output is in the format you actually need on race day -- cumulative split times you can write on your arm or program into a pace band -- rather than just a single predicted time.

2. Runner's World Race Time Predictor

Runner's World includes a race time predictor built into its training tools section. Input a recent race time and the target race distance, and it returns a predicted finish time using a variation of Riegel's formula.

The Runner's World tool is reliable for the core calculation, though it does not generate per-mile split targets or cumulative times as its primary output. For that, you need to pair it with a separate pace calculator. The strength of Runner's World as a resource is the surrounding training content: articles on how to interpret predictions and adjust them for training volume, race conditions, and experience level.

3. World Athletics World Records Reference

Understanding how elite athletes pace races helps contextualize your own targets. World Athletics maintains the official database of world records at all distances, including the split times from record-setting performances.

Looking at how a world record marathon was paced -- what the 5K, 10K, and half marathon split times were in the final record -- illustrates the negative split principle in its most refined form. Elite performers do not go out fast and hang on; they pace with precision and build in the second half. The World Athletics records database makes this data accessible.

Photo by herbert2512 on Pixabay

4. Strava's Training Analysis Tools

Strava is primarily a training log and social platform, but its analysis tools are genuinely useful for pacing work. The segment analysis feature lets you compare your pace across the same course section at different points in a run or race, which is a direct way to measure whether you are running even, positive, or negative splits consistently.

The fitness and freshness graphs track your training load over time, which is useful for timing a peak and ensuring you are not going into a goal race overtrained. The estimated race times Strava generates from your recent activities use VO2 max estimates rather than Riegel's formula, which makes them a useful second opinion alongside a pure Riegel calculation.

5. McMillan Running Calculator

The McMillan calculator is a well-known training pace calculator that goes beyond basic Riegel predictions. It generates training pace recommendations for every zone -- easy, aerobic, long run, tempo, threshold, VO2 max, speed -- derived from a single input race time.

The strength of McMillan's approach is the specificity of the training zones and the way they relate to different types of workouts. A runner who wants to know exactly what pace to target in a 400m interval workout or a 3-mile tempo run can use the McMillan output as a starting point.

The McMillan calculator is free for basic predictions and is widely used in structured marathon training programs.

6. Your GPS Watch's Built-In Predictor

Most current GPS training watches include a race time predictor built into the firmware, typically derived from the watch's estimated VO2 max for your profile. Garmin, Polar, and COROS all offer this feature.

The advantage of the watch-based predictor is that it draws from your actual training data -- recent runs, heart rate data, pacing patterns -- rather than a single time trial result. This makes it potentially more accurate than a formula-based prediction, especially during a training block where you have not raced recently.

The limitation is opacity: the watch's prediction is a black box. You cannot tell whether it is accounting for recent fitness improvements, and the output does not include the split targets and pace zones you need for race-day planning.

Use the watch prediction as a reference and cross-check it against a Riegel formula prediction from your most recent race or time trial.

Photo by the5th on Pixabay

How These Tools Work Together

The most useful approach is to combine tools:

Use a recent race result as input to the EvvyTools pace calculator or McMillan to generate predicted finish times and training pace zones
Cross-check that prediction against your GPS watch's built-in estimate
Use Runner's World resources to understand how training volume and conditions should adjust the raw prediction
Use Strava's segment analysis to validate in training that you are hitting the pace zones you calculated
On race day, use the cumulative split targets from the pace calculator to structure your pacing plan

No single tool does all of this. Together, they give you a data-based framework for training and racing that replaces "running by feel" with calibrated targets derived from your actual current fitness.

Creating a Pace Band for Race Day

Once you have a predicted finish time and target paces from any of these tools, the most practical race-day format is a pace band: a paper strip showing your cumulative split times at each mile or 5K marker.

For a 4:00 marathon running even splits (9:09/mile):

Mile 5: 0:45:45
Mile 10: 1:31:30
Half marathon (13.1): 1:59:59
Mile 18: 2:44:42
Mile 20: 3:03:20
Finish: 4:00:00

For a negative split version with a conservative first half (9:21/mi first half, 8:57/mi second half), each early milestone shifts by 10-15 seconds and the back-half markers accelerate. The EvvyTools pace calculator generates these cumulative splits as part of its output -- print the results before race day, cut the strip to wrist width, and you have a pace band that requires no battery, survives sweat and rain, and is readable with a single glance.

Most experienced coaches recommend the cumulative split format over per-mile pace alone because the arithmetic is done in advance rather than at mile 20 when mental resources are already under load. You check the cumulative time, compare it to the number on your band, and adjust pace accordingly -- no math required.

The Underlying Math

All of these tools, to varying degrees, build on Riegel's power law formula for race time prediction. Understanding the math -- what the 1.06 exponent represents, where the formula is most and least accurate, and how to adjust predictions for training volume and conditions -- makes you a better interpreter of any tool's output.

For a detailed breakdown of how Riegel's formula works and when to trust or adjust its predictions, read Riegel's Formula Explained: How Race Time Prediction Actually Works.

How to Build a Password Entropy Calculator in JavaScript

EvvyTools — Thu, 21 May 2026 11:15:32 +0000

Password strength meters are notoriously unreliable. Many just check for the presence of uppercase letters, numbers, and symbols, then map that to a color. A better approach is to calculate entropy directly and translate that to a realistic crack-time estimate. Here is how to build one in browser-native JavaScript, with no dependencies required.

What You Are Building

A function that takes a password string and returns an entropy estimate in bits, plus a rough crack-time estimate based on a realistic offline attack scenario. You will also add a generator function that uses crypto.getRandomValues() for cryptographically secure random output. The complete implementation is under 100 lines of vanilla JavaScript.

Step 1: Determine the Character Set

To calculate entropy, you need to know the size of the character set the password could plausibly use. Analyze the actual characters in the password:

function getCharsetSize(password) {
  let size = 0;
  if (/[a-z]/.test(password)) size += 26;
  if (/[A-Z]/.test(password)) size += 26;
  if (/[0-9]/.test(password)) size += 10;
  if (/[^a-zA-Z0-9]/.test(password)) size += 32; // common symbols
  return size;
}

This is a lower-bound estimate based on observed character types. It assumes the password was drawn from only the character classes present, which slightly underestimates entropy for passwords that happen to omit one class even though they were generated from a larger set. For display purposes, this is accurate enough. If you need a more conservative estimate, you can instead infer the full generation charset from context (e.g., the user set uppercase on, so count uppercase even if the generated password did not include one).

Step 2: Calculate Entropy

Entropy in bits is log2(charsetSize ^ passwordLength). Mathematically this simplifies to passwordLength * log2(charsetSize):

function calculateEntropy(password) {
  if (!password || password.length === 0) return 0;
  const charsetSize = getCharsetSize(password);
  if (charsetSize === 0) return 0;
  const entropyBits = password.length * Math.log2(charsetSize);
  return Math.round(entropyBits * 10) / 10; // one decimal place
}

The Math.log2() function is available in all modern browsers. For environments that require broader compatibility, Math.log(charsetSize) / Math.log(2) is equivalent.

Step 3: Estimate Crack Time

Crack time depends on attack scenario. Use a conservative offline attack rate against bcrypt with a cost factor of 12, which is approximately 100,000 hashes per second on consumer GPU hardware. This is the relevant scenario if a site's password database is ever compromised and the attacker is running hashes offline without any rate limiting:

function estimateCrackTime(entropyBits) {
  const BCRYPT_GUESSES_PER_SECOND = 100_000;
  const totalGuesses = Math.pow(2, entropyBits);
  const secondsOnAverage = totalGuesses / (2 * BCRYPT_GUESSES_PER_SECOND);

  if (secondsOnAverage < 60) return 'less than a minute';
  if (secondsOnAverage < 3600) return `${Math.round(secondsOnAverage / 60)} minutes`;
  if (secondsOnAverage < 86400) return `${Math.round(secondsOnAverage / 3600)} hours`;
  if (secondsOnAverage < 31536000) return `${Math.round(secondsOnAverage / 86400)} days`;
  if (secondsOnAverage < 3.15e9) return `${Math.round(secondsOnAverage / 31536000)} years`;
  return 'centuries';
}

The / 2 in the denominator accounts for the expected value of a brute-force search -- on average you find the target halfway through the search space.

For context, a 60-bit entropy password against bcrypt-12 at 100,000 guesses/second has an average crack time of about 2^59 / 100,000 seconds -- roughly 1.8 * 10^12 seconds, or tens of thousands of years. A 20-character random password from a 95-character set lands at about 131 bits, which moves the average crack time to a number with more digits than are practical to express.

Photo by slightly_different on Pixabay

Step 4: Add Secure Random Generation

Wire up a generator that produces passwords from a specified character set using crypto.getRandomValues():

function generatePassword(length, charset) {
  if (!charset || charset.length === 0) {
    throw new Error('charset cannot be empty');
  }
  const array = new Uint32Array(length);
  crypto.getRandomValues(array);
  return Array.from(array)
    .map(n => charset[n % charset.length])
    .join('');
}

const LOWERCASE = 'abcdefghijklmnopqrstuvwxyz';
const UPPERCASE = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
const DIGITS = '0123456789';
const SYMBOLS = '!@#$%^&*()-_=+[]{}|;:,.<>?';

const charset = LOWERCASE + UPPERCASE + DIGITS + SYMBOLS;
const password = generatePassword(20, charset);
console.log(password, calculateEntropy(password), 'bits');

Note: n % charset.length introduces a small modulo bias when charset.length is not a power of 2. For a 95-character set, the bias per character is well under 0.001% -- negligible for passwords. For higher-stakes applications, use rejection sampling:

function generatePasswordSafe(length, charset) {
  const output = [];
  while (output.length < length) {
    const buf = new Uint8Array(1);
    crypto.getRandomValues(buf);
    if (buf[0] < Math.floor(256 / charset.length) * charset.length) {
      output.push(charset[buf[0] % charset.length]);
    }
  }
  return output.join('');
}

Step 5: Build a Minimal UI

Wire the calculator to a text input to update in real time:

const input = document.getElementById('password-input');
const entropyDisplay = document.getElementById('entropy');
const crackDisplay = document.getElementById('crack-time');

input.addEventListener('input', () => {
  const entropy = calculateEntropy(input.value);
  const crackTime = estimateCrackTime(entropy);
  entropyDisplay.textContent = `${entropy} bits`;
  crackDisplay.textContent = `Estimated offline crack time (bcrypt-12): ${crackTime}`;
});

This is the core of what the EvvyTools Password Generator does -- combined with a more complete character set analysis and polished UI. If you want to compare your implementation's output against a production version, you can inspect the behavior there directly.

Step 6: Validate Against Edge Cases

Before shipping, verify your implementation handles these edge cases cleanly:

Empty string: should return 0 bits and not throw. The guard at the start of calculateEntropy handles this, but test it explicitly.

Single character: a one-character password with one character class has log2(26) ≈ 4.7 bits. Your function should return that, not throw on a charset size of 1.

Non-ASCII input: passwords containing Unicode characters will not match any of the regex classes, returning 0 for charset size. Decide whether to add a Unicode symbol category or to sanitize input before scoring.

Very long passwords: Math.pow(2, entropyBits) overflows to Infinity at about 1024 bits. The crack time function returns 'centuries' before reaching that threshold, but you should verify your entropy display handles large values gracefully rather than showing Infinity bits.

The OWASP Password Storage Cheat Sheet covers what happens on the server side after a password is created -- the hashing algorithm and parameters that determine whether your entropy calculation translates into actual protection. Reading it alongside this guide gives a complete picture of the client-server credential security chain.

What This Does Not Measure

Entropy only models brute-force resistance against randomly generated passwords. If a password is human-chosen, the effective entropy is much lower than the formula suggests because human selections are not uniformly random. A password like "Summer2024!" scores about 57 bits by the character-type formula but is far weaker in practice because it follows a recognizable seasonal-year-symbol pattern that attackers model explicitly.

Pattern-based attacks (dictionary attacks, rule-based mutation) exploit structure in human-chosen passwords. For an accurate estimate on non-random passwords, you would need a tool like Dropbox's zxcvbn library, which models attack strategies rather than calculating theoretical entropy. It estimates guessing difficulty based on known patterns, common words, keyboard walks, and substitution rules.

For the background math on why length typically beats complexity in entropy calculations, and how different hashing algorithms affect the crack-time picture, see How Password Entropy Works and Why It Matters for Account Security.

EvvyTools is a collection of developer and productivity tools. The full tools directory includes generators, formatters, and utilities across multiple categories.

The Web Crypto API documentation on MDN covers crypto.getRandomValues() and the broader set of cryptographic primitives available in modern browsers, including key derivation functions useful for more advanced credential scenarios.