The numerator is the absolute difference. The denominator is the average of the two measurements.

NIST documents this average-based formula as one supported definition of percent difference. It also documents a maximum-based alternative, which is a useful reminder that the denominator must be stated when the result matters. NIST: PERCDIF

Worked example

Suppose two instruments report the length of the same component:

Measurement A = 48 mm
Measurement B = 52 mm

First, find the absolute difference:

|48 - 52| = 4 mm

Then find the average measurement:

(48 + 52) ÷ 2 = 50 mm

Finally:

4 ÷ 50 × 100 = 8%

The two measurements differ by 8% using the average-based formula.

The calculation is symmetric. Switching the labels does not change the answer:

48 vs. 52 = 8%
52 vs. 48 = 8%

That symmetry is why this method works well when neither measurement is the obvious baseline.

Percentage difference is not percentage change

If one value is a baseline, use percentage change instead.

For example, if a process time changes from 48 seconds to 52 seconds:

Percentage change =
(new - old) ÷ old × 100

(52 - 48) ÷ 48 × 100 = 8.33%

This answer is different from the 8% percentage difference because it answers a different question.

Do not label a percentage change as a percentage difference without naming the baseline. The missing baseline is where confusion begins.

A practical software example

Imagine two builds of the same API endpoint:

Build A median response time: 120 ms
Build B median response time: 150 ms

If you are comparing the builds as two peer measurements:

|120 - 150| ÷ ((120 + 150) ÷ 2) × 100
= 30 ÷ 135 × 100
= 22.22%

The measurements differ by about 22.22%.

If Build A is the accepted baseline and Build B is the new deployment, the more useful question is usually percentage change:

(150 - 120) ÷ 120 × 100 = 25%

That tells you the new build is 25% slower relative to the previous one.

The math is easy. Choosing the right interpretation is the real job.

When the formula is useful

Percentage difference is often useful for:

• comparing two manual measurements of the same quantity;

• checking whether two sensors report similar values;

• comparing independent estimates;

• reviewing a calculated result against a separate calculation;

• comparing two implementation benchmarks when neither is the baseline.

It is less useful when the values describe different populations, different units, or different definitions.

For example, do not calculate percentage difference between:

• 20% conversion rate and 20% profit margin;

• 5 kilograms and 5 pounds;

• a monthly average and a single-day measurement;

• two values produced under materially different test conditions.

Convert units, align the population and time range, and document the measurement method before comparing values.

What happens near zero?

The average-based formula becomes unstable when both values are close to zero.

Consider:

A = 0.01
B = 0.03

The absolute difference is only 0.02, but the percentage difference is:

0.02 ÷ 0.02 × 100 = 100%

That is mathematically correct under this formula. It may still be a poor way to communicate practical importance.

If both values are zero, the denominator is zero and percentage difference is undefined. If one or both values can be negative, decide whether a relative comparison is meaningful before applying a generic formula.

In engineering, laboratory, financial, and safety-critical work, report the raw difference and units alongside any percentage. A percentage alone can hide the scale of the measurement.

Percentage points are different again

If the values are already percentages, distinguish percentage difference from percentage points.

Suppose one rate is 40% and another is 50%:

Difference in percentage points = 50% - 40% = 10 percentage points

The relative increase from 40% to 50% is:

(50% - 40%) ÷ 40% × 100 = 25%

The average-based percentage difference is:

|40% - 50%| ÷ ((40% + 50%) ÷ 2) × 100
= 22.22%

All three results are valid calculations. They are not interchangeable.

Use percentage points when comparing rates directly. Use percentage change when one rate is a baseline. Use percentage difference when you are treating two comparable values symmetrically.

A quick checking workflow

Before reporting a percentage difference:

1. Confirm that both values measure the same thing.

2. Confirm that they use the same unit and comparable conditions.

3. Decide whether one value is a baseline.

4. Use percentage difference only when neither value should dominate.

5. State the formula or denominator used.

6. Report the raw difference and units as well.

7. Flag zero and near-zero values instead of forcing a misleading percentage.

You can use ToolExo's Percentage Calculator to check the arithmetic, then document which interpretation applies to the decision you are making.

The short version

Percentage difference answers: "How far apart are these two comparable measurements?"

Percentage change answers: "How much did this value change from a known starting point?"

Pick the question first. Then choose the denominator that makes the result honest.

Sources

• NIST Dataplot: Percent Difference

• NIST Dataplot: ISO 13528 Percentage Difference Score

That answer gives each landing page equal influence. It does not give each visitor equal influence.

The combined result is:

Total conversions = 9 + 50 = 59
Total visitors = 10 + 100 = 110

Combined conversion rate = 59 ÷ 110 × 100
                         = 53.64%

The 70% figure answers a different question: "What is the average rate across two equally weighted pages?" The 53.64% figure answers: "What percentage of all visitors converted?"

For a site-wide conversion rate, the second question is usually the one that matters.

Use the combined numerator and denominator

When each percentage has the form:

percentage = numerator ÷ denominator × 100

the combined percentage is:

combined percentage =
(sum of numerators ÷ sum of denominators) × 100

For several groups:

combined percentage =
(n₁ + n₂ + ... + nₖ) ÷ (d₁ + d₂ + ... + dₖ) × 100

where:

• n is the count represented by the percentage;

• d is its denominator, such as visitors, orders, students, bytes, or tests;

• each numerator must be part of the corresponding denominator.

This is equivalent to a weighted average where the denominators are the weights. NIST gives the general weighted-mean formula as the sum of each value times its weight, divided by the sum of weights. NIST: weighted mean

When a simple average is correct

A plain average is not always a mistake.

It is appropriate when every percentage should carry the same weight, regardless of its denominator.

For example, imagine a course grade with three equally weighted categories:

(80% + 90% + 70%) ÷ 3 = 80%

That is correct because the grading rule explicitly gives each category equal weight.

It is also correct when denominators are equal. If two surveys each include 100 respondents, averaging their percentages gives the same result as combining their counts.

Before calculating, ask one question:

Should each group count equally, or should each underlying observation count equally?

That choice determines the formula.

A grade example with unequal weights

Now consider a course with this grading policy:

The correct calculation is:

92% × 0.20 = 18.4%
75% × 0.30 = 22.5%
80% × 0.50 = 40.0%

Final grade = 18.4% + 22.5% + 40.0%
            = 80.9%

Here, the category weights are not denominators. They are an explicit policy decision. The weighted-average structure is still the same, but the weights come from the syllabus rather than raw counts.

Do not average percentages with incompatible meanings

Sometimes neither a simple average nor a weighted average is meaningful.

Do not combine percentages when the underlying definitions differ. Examples include:

• a conversion rate based on visitors and a conversion rate based on sessions;

• an email open rate and a click-through rate;

• a tax rate and a discount rate;

• two survey results that use different questions or populations;

• a gross-margin percentage and a net-margin percentage.

The arithmetic may work, but the result may not describe anything useful.

Write down the numerator, denominator, population, time range, and definition for every rate before combining it. If they do not match, report them separately or redesign the metric.

Percentage points are not percent changes

This is another common source of bad summaries.

If a rate rises from 2% to 3%, it increased by:

3% - 2% = 1 percentage point

Relative to the original 2%, it increased by:

(3% - 2%) ÷ 2% × 100 = 50%

Both statements are mathematically correct. They answer different questions.

Use percentage points when comparing rates directly. Use relative percentage change when you want to describe change relative to the original value. Do not average the two concepts together.

What if you only know the percentages?

If you know only that one group had a 90% rate and another had a 50% rate, you cannot calculate their overall rate unless you also know the denominators or the intended weights.

The overall rate could be close to 90%, close to 50%, or somewhere between them. It depends on the group sizes.

In that situation, do not invent an overall percentage. You can:

1. request the underlying counts;

2. state that the simple average assumes equal group weight;

3. keep the rates separate;

4. report a weighted result only when the weights are documented.

A quick workflow for reports and dashboards

Before publishing an average percentage:

1. Write every percentage as a numerator and denominator.

2. Confirm that the groups measure the same thing over compatible periods.

3. Decide whether observations or groups should have equal influence.

4. Sum counts when observations should have equal influence.

5. Use documented weights when a policy assigns them.

6. Label the result clearly: combined rate, equally weighted average, or weighted score.

7. Keep enough detail for someone else to reproduce the result.

For a quick check of percentage differences, reversals, and related calculations, use ToolExo's Percentage Calculator. For a weighted average, first make the weights explicit rather than treating a list of percentages as interchangeable.

The short version

You can directly average percentages when their denominators are equal or when equal group weighting is the intended rule.

When group sizes differ and you need one overall rate, add the numerators, add the denominators, and divide once. That keeps the result tied to the people, items, visits, or observations the percentage is supposed to represent.

Sources

• NIST: Weighted Mean

• OpenStax: Measures of Center and Weighted Mean

• OpenStax: Understanding Percent

Suppose the query parser decodes it once:

reports%2F2026.csv

A validation function sees no literal slash and accepts it. Later, another helper calls decodeURIComponent() before joining the value to a directory:

reports/2026.csv

The validator approved one representation. The file operation used another.

The risk is larger with path traversal input:

%252E%252E%252Fsecrets.txt

One decode produces:

%2E%2E%2Fsecrets.txt

A second decode produces:

../secrets.txt

OWASP documents double encoding as a way to bypass filters that inspect input before a later layer decodes it again. The technique can affect traversal checks, redirect validation, and output handling. OWASP: Double Encoding

Decide who owns decoding

Every request path should have an explicit representation boundary:

1. Raw request target or raw form body.

2. Parsed query, route parameter, or form field.

3. Validated application value.

4. Context-specific use, such as a database lookup or generated URL.

The key rule is simple: decode once for each documented format boundary, then validate the same representation that the sensitive operation will use.

That does not mean "never decode twice" in every situation. A URL can legitimately contain another URL as a query parameter. In that case, parse the outer URL first, then treat the extracted inner value as a separate URL with its own parsing and allowlist rules.

What causes trouble is repeatedly decoding one untyped string until it looks readable.

Do not add a second decode because a percent sign remains

A remaining % is not proof that something is broken.

For example, a system may intentionally store %2F as data, or an outer URL may contain an encoded inner URL. Calling decodeURIComponent() again without understanding the format changes the value and may create a delimiter that did not exist at the validation boundary.

The same caution applies to framework helpers. Some routers and query parsers already return decoded values. Before decoding a route parameter or a parsed query value manually, verify whether the framework has already done it.

Malformed sequences should also fail visibly. In JavaScript, decodeURIComponent() throws a URIError for invalid percent escapes or invalid UTF-8 sequences. Catch that error and return a clear client error rather than silently repairing the value. MDN: malformed URI sequence

function decodeOneComponent(raw: string): string {
  try {
    return decodeURIComponent(raw);
  } catch {
    throw new Error("Invalid percent-encoded input");
  }
}

Use a function like this only when raw is known to be an encoded component. Do not pass an already-parsed route value to it by habit.

Validate for the destination, not for appearance

URL decoding is not a security control by itself. The final validation must match the destination.

For a file identifier, use an allowlist grammar such as:

^[A-Za-z0-9._-]+$

Then resolve the final path with platform path APIs and verify that the resolved path remains inside the intended directory.

For redirects, parse the final URL and allow only approved origins. A string check such as startsWith("https://example.com") is not enough.

For generated links, encode the individual query value or path segment. Do not encode an entire URL after assembling it, because that can escape structural delimiters that need to remain structural.

A small test set catches most ownership mistakes

Add tests that preserve both the raw input and the value at each boundary:

When a production bug appears, log the representation safely at each owned boundary. Avoid logging secrets, tokens, or personal data. The useful question is not "what did the input look like?" It is "which layer turned it into the value used by the application?"

For a quick local check of one decode pass, you can use ToolExo's URL Encoder & Decoder. It keeps the conversion in the browser and is useful for comparing component and form-style encoding.

Keep the rule boring

Most URL decoding bugs come from unclear ownership, not exotic encoding.

Name the boundary. Decode once at that boundary. Validate the resulting value for its actual destination. Then pass typed, validated data forward instead of another string that a later helper may decode again.

That approach makes %252F less mysterious. More importantly, it makes the authorization check and the final operation agree on what the request means.