Vector Distance Suite

Compare embedding vectors with cosine, dot, Euclidean, and Manhattan distance.

Calculate all common vector similarity and distance metrics at once — cosine similarity, dot product, Euclidean (L2) and Manhattan (L1) distance — from two pasted vectors. Useful for benchmarking RAG retrieval strategies without running code. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Which metric should I use for embeddings?

Most text-embedding models are tuned for cosine similarity or dot product. If your vectors are normalised to unit length, cosine, dot, and Euclidean rank results identically, so the choice often comes down to what your vector database supports.

Vector distance suite

Different vector databases and embedding models expect different distance functions, and the choice subtly changes which results rank highest. This tool computes the four metrics you actually care about — cosine similarity, dot product, Euclidean (L2) distance, and Manhattan (L1) distance — for the same pair of vectors, so you can compare them at a glance and match your retrieval configuration without writing a script.

How it works

The tool parses both inputs into equal-length number arrays and computes each metric directly:

  • Cosine similarity — dot product divided by the product of L2 norms; range −1 to 1.
  • Dot product — sum of element-wise products; unbounded, magnitude-sensitive.
  • Euclidean (L2) distance — square root of the sum of squared differences.
  • Manhattan (L1) distance — sum of absolute differences.

It also reports cosine distance (1 − cosine) since many databases express similarity that way. All four update instantly as you edit either vector.

When each metric is the right choice

Cosine similarity is the standard for text and document embeddings. Because it measures the angle between vectors rather than their absolute positions, it is unaffected by vector length. Two documents that discuss the same topic but one is twice as long will still score near 1.0 if they were embedded with a length-normalizing model. Most sentence-transformer and OpenAI embedding models are designed to be used with cosine similarity.

Dot product is used when your embedding model was trained with a dot-product objective — for example, bi-encoder models trained with in-batch negatives often optimize dot product directly. In that setting, dot product rankings match the training signal and cosine similarity may underperform. Check your model’s documentation for the recommended distance function.

Euclidean (L2) distance is the right choice when magnitude carries genuine meaning. Some clustering and image embedding pipelines treat distance in absolute space rather than angle space. L2 penalizes large differences in individual dimensions more heavily than L1, making it sensitive to outlier features.

Manhattan (L1) distance is more robust to high-dimensional outliers than Euclidean distance. In very high-dimensional spaces both L1 and L2 suffer from the curse of dimensionality, but L1 tends to preserve more signal at dimensions above a few hundred.

A concrete verification example

If you have a sentence-transformer model returning 384-dimensional vectors, paste two similar sentences’ embeddings and check the cosine similarity. A well-matched pair (for example, “the dog chased the cat” and “a dog was running after a cat”) should score above 0.85 with a good model. Semantically unrelated sentences typically score below 0.4. If your model’s cosine scores are all clustering in a narrow range near zero, the vectors may not be normalized — check the Euclidean magnitude; it should be close to 1.0 for normalized embeddings.

Metric and database pairing

Database / LibraryDefault metricNotes
PineconeCosine or dot productSet at index creation
WeaviateCosineConfigurable per class
QdrantCosine or dotSet per collection
FAISSL2 or inner productInner product ≈ dot product
pgvectorL2, cosine, or innerOperator class at index creation

Mismatch between the metric you use here and the metric your index was built with can cause ranking discrepancies that are hard to debug — always verify they match.

  • Normalise to compare fairly. On unit-length vectors, cosine and dot product agree and Euclidean ranking matches cosine — useful for verifying your embeddings are normalised.
  • Watch magnitude with dot product. If one vector is much longer, dot product can rank it high even when its direction is a poor match.
  • Local only. Nothing leaves your browser.