Differential Privacy Noise Budget Calculator

Key Concepts: Privacy Budget, Epsilon, Delta, and Sensitivity

Privacy budget and epsilon ($\epsilon$)

Differential privacy controls how much the output of an analysis can change when a single individual’s data is modified. The parameter $\epsilon$ (epsilon) quantifies this guarantee. Intuitively, smaller $\epsilon$ means stronger privacy but also more noise and lower accuracy. Larger $\epsilon$ relaxes privacy in exchange for higher accuracy.

A privacy budget is the total $\epsilon$ you are willing to spend for a project or dataset. Each query that is answered with a DP mechanism consumes some of this budget. When the budget is exhausted, you should stop releasing additional results or reset the dataset and plan a new budget.

Delta ($\delta$)

Some mechanisms, especially the Gaussian mechanism, provide ($\epsilon$, $\delta$)-differential privacy. The parameter $\delta$ is a small failure probability: with probability at most $\delta$, the guarantee of pure $\epsilon$-DP may not hold. In practice, $\delta$ is often set to something much smaller than 1 / N, where N is the dataset size (for example, ${10}^{-6}$ or ${10}^{-8}$).

Query sensitivity ($\Delta f$)

Sensitivity $\Delta f$ measures how much the result of a query can change when one individual’s data is added, removed, or modified. Formally, it is the maximum difference in the query output over all neighboring datasets that differ in one individual.

• Simple counting queries (e.g., number of users matching a filter) usually have sensitivity $\Delta f=1$.
• More complex queries, such as sums with bounded contributions or averages with clipping, can have higher sensitivity depending on the bounds you enforce.

These ideas interact. A small budget, a large number of queries, and a high sensitivity query all push the required noise upward. That is why DP planning is rarely about one parameter in isolation; it is about the balance between all of them.

Mathematical Formulas Used by the Calculator

The page computes just a few quantities, but each one follows directly from standard textbook formulas. Writing them out makes the calculator easier to audit and helps you translate its output into code or documentation.

Per-query epsilon allocation

The calculator assumes that the total privacy budget ${\epsilon }_{\text{total}}$ is divided equally across the allowed number of queries $Q$. The per-query budget is

where:

• ${\epsilon }_q$ is the per-query epsilon allocation.
• ${\epsilon }_{\text{total}}$ is the total project-level privacy budget.
• $Q$ is the Total Allowed Queries you specify.

Laplace mechanism noise scale

For the Laplace mechanism, the noise added to a query output comes from a Laplace distribution with scale parameter $b$. For a query with sensitivity $\Delta f$ and per-query epsilon ${\epsilon }_q$, the scale is

Formula: b = (Δ f) / ε_q.

$b=\frac{\Delta f}{{\epsilon }_q}.$

Larger sensitivity or smaller per-query epsilon leads to a larger scale $b$, meaning more noise is added to the answer.

Gaussian mechanism noise scale (standard deviation)

For the Gaussian mechanism, the calculator uses a standard analytic bound for (${\epsilon }_q$, $\delta$)-DP. The noise added is Gaussian with standard deviation $\sigma$ given approximately by

Formula: σ = (Δ f sqrt(2 ⁢ ln ⁡ (1.25 / δ))) / ε_q.

$\sigma =\frac{\Delta f\sqrt{2\ln \left(\frac{1.25}{\delta }\right)}}{{\epsilon }_q}.$

Here, $\delta$ must be a small positive number, and the formula is most appropriate when $\delta$ is very small (e.g., ${10}^{-5}$ or smaller) and ${\epsilon }_q$ is not extremely large.

In plain language, both mechanisms scale noise in proportion to sensitivity and inversely with epsilon. Gaussian noise adds one more ingredient, $\delta$, which affects the multiplier through the logarithm term.

How to Use the Calculator

The form is short, but each field carries an assumption. If you understand what each input means, the output becomes much easier to trust and much easier to explain to other stakeholders.

1. Set the Total Privacy Budget ($\epsilon$)
   Choose the total epsilon you are willing to spend for this dataset or project. Typical values in practice might range from about 0.1 (very strict) to 5 or more (looser). The smaller this value, the more noise will be required.
2. Specify the Total Allowed Queries
   Enter how many queries or releases you plan to support under this budget. The tool divides the total $\epsilon$ evenly across this number, so doubling the query count halves the per-query epsilon.
3. Enter the Query Sensitivity ($\Delta f$)
   For simple counts, use 1. For sums or averages, compute or bound the maximum effect of one individual on the output based on your clipping or normalization rules.
4. Choose the Mechanism
   Select Laplace for pure $\epsilon$-DP, or Gaussian if your system uses ($\epsilon$, $\delta$)-DP. When you choose Gaussian, you also need to set $\delta$.
5. Set Delta ($\delta$) for Gaussian (if applicable)
   Use a small value such as 1e-5 or smaller. As a rule of thumb, $\delta$ should be less than 1 / N, where N is the dataset size, and often much smaller for sensitive data.
6. Track Queries Used So Far
   As you issue queries over time, update this field. The calculator will estimate how much of the budget has been consumed and how much remains if you continue to allocate epsilon evenly.

If you are still choosing policy values, it often helps to try several scenarios. For example, keep sensitivity fixed and vary the number of allowed queries. You will immediately see how rapidly the per-query epsilon shrinks and how quickly the noise scale grows.

Interpreting the Results

The calculator reports several useful quantities derived from your inputs:

• Per-query epsilon: how much of the privacy budget each query is allowed to consume under equal allocation.
• Noise scale (Laplace $b$ or Gaussian $\sigma$): the magnitude of random noise that should be added to each query’s output.
• Consumed budget: an estimate of how much of ${\epsilon }_{\text{total}}$ has been spent given the Queries Used So Far.
• Remaining budget: how much $\epsilon$ is left if you continue using the same per-query allocation.

If the remaining budget is close to zero or negative, your planned number of queries is not compatible with the chosen total $\epsilon$. You can address this by reducing the number of queries, accepting more noise (smaller per-query epsilon), or increasing the total privacy budget after a careful policy review.

The most common interpretation mistake is to treat the noise scale as a quality score by itself. It is not. A scale of 5 may be acceptable for a large aggregate count and unacceptable for a small bounded sum. Always compare the noise magnitude with the typical size and variability of the quantity you plan to release.

Worked Example

Consider an analytics project with the following plan:

• Total privacy budget: ${\epsilon }_{\text{total}}=1.0$
• Total allowed queries: $Q=100$
• Query type: counting queries ($\Delta f=1$)
• Mechanism: Laplace

The per-query epsilon is

Formula: ε_q = 1.0 / 100 = 0.01.

${\epsilon }_q=\frac{1.0}{100}=0.01.$

For the Laplace mechanism, the noise scale is

Formula: b = (Δ f) / ε_q = 1 / 0.01 = 100.

$b=\frac{\Delta f}{{\epsilon }_q}=\frac{1}{0.01}=100.$

This means each query result will have Laplace noise with scale 100 added. If your counts are typically on the order of a few thousand, this may be acceptable; if they are much smaller, you may find the noise too large and need to reconsider your budget or number of queries.

Now suppose you have already used 40 queries. Under the equal allocation assumption, you have consumed

Formula: 40 × 0.01 = 0.4

$40\times 0.01=0.4$

of your privacy budget, leaving $0.6$ remaining. The calculator will display this remaining budget, helping you decide whether you can afford additional queries at the same noise level.

The same pattern extends to Gaussian noise. The exact number changes because of the additional logarithmic factor involving $\delta$, but the planning lesson is identical: more queries or tighter privacy mean more noise per release.

Laplace vs Gaussian Mechanisms

The table below summarizes some high-level differences between the Laplace and Gaussian mechanisms as used in this calculator.

Neither option is universally better. The right choice depends on your threat model, the DP definition used by your system, and the accounting method in your implementation stack.

Assumptions and Limitations

This calculator is intentionally simple and makes several assumptions that you should keep in mind:

• Equal per-query allocation: The total $\epsilon$ is divided equally across all queries. Real systems often allocate different amounts to different queries based on sensitivity and importance.
• Basic composition: The calculation of consumed and remaining budget assumes that privacy losses add up linearly (basic composition). In practice, advanced composition, Rényi DP, or moments accountants can provide tighter bounds when many queries are issued.
• Sensitivity must be correctly specified: The tool does not verify or compute $\Delta f$ from your data. You must derive an appropriate sensitivity bound from your query design, clipping rules, and data constraints.
• Approximate Gaussian formula: The Gaussian mechanism formula implemented here is a common analytic approximation valid for small $\delta$. It does not replace a full privacy accountant for complex pipelines or iterative algorithms like DP-SGD.
• Not legal or compliance advice: Outputs are for estimation and planning only. Relying solely on this calculator for regulatory compliance or high-stakes privacy guarantees is not recommended. Always consult dedicated DP libraries, documentation, and experts for production deployments.
• No dataset size input: The tool does not know your dataset size. You must ensure that your chosen $\epsilon$ and $\delta$ values are appropriate for the size and sensitivity of your data.

That may sound like a long list of caveats, but it is exactly what makes the calculator useful: it is transparent about what it does and does not model. For rough budgeting, that transparency is often better than a black-box estimate.

Typical Ranges for Epsilon and Delta

There is no universally correct choice of $\epsilon$ and $\delta$, but some broad guidelines can prevent extreme misconfigurations:

• Epsilon: Values below 0.1 are often considered very strict; 0.1–1 provide strong privacy with moderate noise; values above 5 may be considered weak in some contexts but can be appropriate for low-risk or highly aggregated data.
• Delta: Choose $\delta$ much smaller than 1 / N, where N is your dataset size. For large datasets, typical choices range from ${10}^{-5}$ to ${10}^{-10}$ depending on risk tolerance and applicable guidelines.

These ranges are descriptive, not prescriptive. The right settings depend on the expected harm from disclosure, the size of the data population, the purpose of the analysis, and the policy framework around the release.

Practical Workflow Tips

In practice, teams get the most value from a calculator like this when they use it early and revisit it often. A DP plan that looks reasonable before a project starts can drift once stakeholders request more dashboards, more slices, or more frequent reports.

• Use the calculator early in design to understand the trade-off between number of queries, privacy strength, and noise magnitude.
• Keep track of Queries Used So Far as analyses proceed, especially in recurring reporting or dashboard scenarios.
• Revisit the budget if you introduce new, more sensitive queries or expand the number of releases beyond the original plan.
• When moving from this planning tool to implementation, rely on vetted DP libraries that implement composition, accounting, and sampling correctly.

Summary

This differential privacy noise budget calculator offers a simple way to connect abstract privacy parameters ($\epsilon$, $\delta$, and sensitivity) to concrete per-query noise scales for Laplace and Gaussian mechanisms. By assuming equal per-query allocation and basic composition, it helps you reason about how many queries your budget can support and how noisy each result will be. However, because it omits advanced composition, detailed accounting, and dataset-specific constraints, its outputs should be treated as planning guidance rather than definitive guarantees.