Minkowski Distance Calculator

Four steps, no sign-up, and nothing to install. Every figure is recomputed as you type, in your browser.

1. Enter the two vectors. Type or paste vector A and vector B with the same number of values. Separate the numbers with commas, spaces, or new lines. Pasted brackets like [1, 2, 3] and scientific notation like 3e2 both parse.
2. Choose the order p. Set p ≥ 1. Use p = 1 for Manhattan, p = 2 for Euclidean, or any value such as 1.5 or 3 for the general Lₚ metric. Anything below 1 is rejected, because the result would not be a true metric.
3. Read the distance. The headline figure is the Minkowski distance at your p. Beside it sit the Manhattan, Euclidean, and Chebyshev special cases over the same pair, so you can see where your order lands between the L1 ceiling and the L∞ floor.
4. Check the working. The per-dimension table shows each absolute difference and that difference raised to p, the scaled cross-check confirms the total by an overflow-safe second route, and the copy-ready SciPy snippet reproduces the same number in Python.

The Minkowski distance is the generalized Lₚ metric. For two equal-length vectors a = [a₁…aₙ] and b = [b₁…bₙ] and an order p ≥ 1, it is the p-th root of the sum of the p-th powers of the absolute coordinate differences. It is the metric family scikit-learn and SciPy use for nearest-neighbour search, and Manhattan, Euclidean, and Chebyshev distance are all special cases of it.

dₚ(a, b) = ( Σ |aᵢ − bᵢ|ᵖ )^(1/p) = ( |a₁ − b₁|ᵖ + … + |aₙ − bₙ|ᵖ )^(1/p)

The tool computes this in three steps:

1. Per-dimension absolute difference. Subtract the vectors coordinate by coordinate and take the magnitude: dᵢ = |aᵢ − bᵢ| (the NIST / SciPy definition).
2. Raise to p and sum. Raise each difference to the power p and add them: S = Σ dᵢᵖ , the inner sum used by scikit-learn's DistanceMetric "minkowski".
3. Take the p-th root. The distance is dₚ = S^(1/p), matching scipy.spatial.distance.minkowski(a, b, p).

The named metrics are just specific orders of the same sum, and the tool reports all three alongside your chosen p:

• p = 1 → Manhattan (L1): Σ |aᵢ − bᵢ|, the city-block path.
• p = 2 → Euclidean (L2): √( Σ (aᵢ − bᵢ)² ), the straight line.
• p → ∞ → Chebyshev (L∞): maxᵢ |aᵢ − bᵢ|, the largest single-axis gap.

Chebyshev is computed directly via the maximum rather than by plugging a huge number in for p, because |aᵢ − bᵢ|ᵖ would overflow to infinity for a large finite p. p ≥ 1 is enforced because the triangle inequality, and therefore a true metric, fails for 0 < p < 1. All arithmetic is done in double-precision floating point on the raw inputs and is rounded only for display. As a credibility check, the calculator recomputes the distance a second way, an overflow-safe scaled form that factors out the largest difference before raising it to p, and confirms the two routes agree, so even inputs around 10⁹ stay exact at everyday orders.

What the order p actually changes

Raising each gap to p before summing, then undoing it with the p-th root, is a way of asking how much the biggest single gap should count. At p = 1 every dimension contributes its raw difference and nothing is privileged. Push p up and the large gaps grow faster than the small ones, so they take over the sum; in the limit the small gaps vanish from the answer entirely and only the maximum survives. One consequence is worth remembering: for a fixed pair of vectors, dₚ is non-increasing in p. Manhattan is therefore always the ceiling, Chebyshev always the floor, and every other order sits between them. Here is the whole sweep for the default pair a = [1, 2, 3] and b = [4, 0, 3], whose axis gaps are 3, 2 and 0:

The zero gap in the third dimension contributes nothing at any order, which is the general rule: a dimension where the two vectors agree never affects the distance, however you set p. By p = 10 the answer is within 0.2% of the Chebyshev value, which is why orders above about 10 are rarely worth the trouble. If that is the behaviour you want, take it from the Chebyshev distance calculator instead, where the maximum is computed exactly rather than approached.

Scale, units and normalisation

Every Lₚ metric adds raw coordinate gaps, so it inherits whatever units your features carry. Mix a monthly salary column in rupees with an age column in years and the salary gaps decide every neighbour, not because salary matters more but because its numbers are larger. The fix comes before the distance, not after it: put each column on a comparable scale, either min-max to the 0 to 1 range or a z-score built from the column mean and standard deviation. Higher p makes the problem worse, since a large gap is magnified more at p = 3 than at p = 1, so a low order is the gentler choice when you cannot scale. And if what you care about is the direction two vectors point in rather than how far apart they are, no Lₚ order will give it to you: cosine similarity is the measure for that, and it ignores vector length by construction.

Weights, and the same number in code

The metric treats every dimension as equally important, which is often not what you mean. The weighted form puts a coefficient on each term before the root, dₚ = ( Σ wᵢ |aᵢ − bᵢ|ᵖ )^(1/p), and that is exactly what SciPy's w= argument computes. This calculator is deliberately unweighted, but you can reproduce any weighting in it without changing the formula: scale dimension i of both vectors by wᵢ^(1/p) before pasting, because wᵢ|dᵢ|ᵖ = (wᵢ^(1/p) · dᵢ)ᵖ. Weighting is the lever to reach for when a column deserves more say than its raw spread gives it; when the problem is units rather than importance, rescale the column instead with the feature scaling calculator.

In code the whole thing is one line. In NumPy it is np.sum(np.abs(a - b) ** p) ** (1 / p); in SciPy, scipy.spatial.distance.minkowski(a, b, p); and for every pair in a matrix at once, sklearn.metrics.pairwise_distances(X, metric="minkowski", p=p). All three return the figure this page shows. The one difference worth knowing is the Chebyshev limit: SciPy and this tool both compute it as the maximum, so ask for metric="chebyshev" rather than passing a huge p, which overflows in NumPy as readily as it does here.

Choosing p for KNN and clustering

scikit-learn's KNeighborsClassifier and KNeighborsRegressor both default to metric="minkowski", p=2, so the out-of-the-box behaviour is ordinary Euclidean distance. Treating p as a hyperparameter and grid-searching it over 1, 1.5 and 2 costs almost nothing and sometimes moves accuracy, because it changes which neighbours count as close. p = 1 suits data with a few noisy, wide-ranging columns, since an absolute value does not punish one outlying feature as hard as a square does. p = 2 suits roughly spherical, already-scaled clusters. Dimension count matters too: as the number of features grows, the gap between the nearest and farthest point in an Lₚ ball narrows and all distances begin to look alike, an effect that gets worse as p increases. With wide feature sets, lower orders usually keep more of the contrast, which is a practical argument for trying p = 1 before p = 2 on high-dimensional tables rather than after.

Edge cases the tool handles

• Unequal lengths. Minkowski distance is defined only for vectors of the same dimension, so the tool refuses the pair and names both lengths rather than padding with zeros or returning NaN. If your vectors are different lengths because they are strings, Levenshtein distance is the measure that accepts them.
• Identical vectors. The inner sum is 0 and the distance is exactly 0 at every order, labelled as identical. There is no divide-by-zero: the p-th root of 0 is 0.
• Negative coordinates. Only magnitudes enter the sum, so signs cancel out. a = [−1, −2] to b = [2, 2] has gaps of 3 and 4 and the same distances as a pair of positive vectors with those gaps.
• Non-integer p. Orders like 1.5 or 2.7 are valid and handled with the same code path, which is what makes a grid search over fractional orders possible.
• p below 1. Rejected with an explanation rather than a number, because the triangle inequality fails there and the result would not be a metric. SciPy and scikit-learn refuse it too.
• Very large values. Gaps around 10⁹ are fine at ordinary orders. The hard limit is arithmetic, not the tool: a double overflows above about 1.8 × 10³⁰⁸, so a 10⁹ gap raised to p stops being representable past roughly p = 34.2. Beyond that the headline value shows ∞ while the scaled cross-check still reports a finite figure, which is the signal to divide your vectors through by a constant or use a smaller p. Rescaling both vectors by the same factor scales the distance by that factor exactly.
• Messy input. Commas, spaces, tabs, new lines and pasted brackets like [1, 2, 3] all parse. Scientific notation such as 3e2 is accepted. A token that is not a finite number is reported by position instead of silently becoming NaN.

Minkowski is one family, not the whole field. Choosing a metric is really a statement about what your columns mean, so it helps to know which measure assumes what. These are the ones that come up in practice, each with its own page and working here:

• Manhattan (L1) adds the raw axis gaps. The p = 1 case, and the least sensitive Lₚ order to a single outlying feature.
• Euclidean (L2) is the straight line, the p = 2 case, and the default almost everywhere.
• Chebyshev (L∞) keeps only the largest gap. The p → ∞ limit, and the right answer for king-move or eight-connected grids.
• Cosine similarity measures the angle between vectors and ignores their length, which is why text embeddings and TF-IDF vectors are usually compared with it rather than with an Lₚ distance.
• Mahalanobis divides through by the data's covariance, so correlated features stop being counted twice. Use it when two columns move together.
• Canberra divides each gap by the size of the two values, so a 1-to-2 change counts for more than a 1000-to-1001 one. Suited to counts and sparse data.
• Hamming counts positions that differ, for binary codes and categorical vectors where the size of a difference is meaningless.
• Levenshtein counts single-character edits between two strings, which is how fuzzy name and address matching is scored.

A useful shortcut when deciding: if your features are numeric, scaled and independent, stay in the Lₚ family and tune p. If they are correlated, go Mahalanobis. If magnitude is an artefact of document length or units, go cosine. If they are categories or text, leave numeric distance behind.

Two of the most common reasons people reach a distance calculator are geometry and maps, and the formula answers one of them cleanly and the other not at all.

Points in 2D or 3D space. A point is just a short vector, so the same tool handles it. For 3D coordinates (x, y, z), enter the three numbers per point and set p = 2 for the ordinary straight-line distance √(Δx² + Δy² + Δz²), which is the Pythagorean theorem applied twice. Other orders still mean something physical here: p = 1 is the distance travelled by a machine that moves one axis at a time, such as a 3-axis CNC or a gantry, and p → ∞ is the time taken by one that moves all three axes at once at the same speed, since the longest axis decides when the move finishes. That is a real reason to care about the order rather than a curiosity.

Distance on a map. Latitude and longitude are angles, not lengths, and a degree of longitude shrinks as you move away from the equator. Near Colombo, at about 6.9° N, a degree of latitude is roughly 110.6 km and a degree of longitude roughly 110.5 km, close enough that the mistake hides. At 50° N the longitude degree has shrunk to about 71.6 km and the same sum is visibly wrong. Great-circle distance needs the haversine formula on a sphere, and a journey you can actually drive needs the road network, which is longer again: Colombo to Kandy is about 94 km straight-line but roughly 115 km by road, because the route follows valleys and towns. For town-to-town kilometres in Sri Lanka use the Sri Lanka road distance calculator, and keep Lₚ distance for feature vectors, embeddings and abstract coordinate space. If you only need the plain two-dimensional straight line on a flat plane, the Euclidean distance calculator is the shorter route to it.

• scikit-learn: sklearn.metrics.DistanceMetric, "minkowski" (definition d(x,y) = (Σ |xᵢ − yᵢ|ᵖ)^(1/p); default KNN metric at p=2)
• SciPy: scipy.spatial.distance.minkowski (reference implementation and the p ≥ 1 validity constraint; the cross-check oracle)
• NIST Dictionary of Algorithms and Data Structures: Lₘ distance / Minkowski metric and its limiting cases (Manhattan, Euclidean, Chebyshev)
• scikit-learn: KNeighborsClassifier (the metric="minkowski", p=2 default behind the KNN guidance above)

The formulas on this page were last cross-checked against these sources on 2026-06-11. Minkowski distance is a stable mathematical definition, so this tool needs no rate or schedule updates, only the worked examples are periodically re-reconciled against SciPy.