What the Embedding Similarity Explorer does
This calculator compares embedding vectors: paste a query vector and any number of candidates, and it ranks them by cosine similarity, dot product, Euclidean or Manhattan distance, checks that every vector has the same number of dimensions, and tells you whether they are normalised - the one fact that decides whether cosine and dot product agree.
It is useful for debugging a retrieval pipeline (why did this passage outrank that one?), for checking an export from a vector database, and for learning how the metrics behave. The maths runs in your browser on the numbers you paste; no model is called and nothing is uploaded.
How to use it
- Paste the query vector - a JSON array such as the embedding field of an API response.
- Paste the candidates: a JSON array of arrays, a list of objects with id and embedding, an object mapping ids to vectors, a full embeddings API response, or one vector per line with a label first. You can also drop a JSON, JSONL or CSV file.
- Choose the metric to rank by. Every metric is shown in the table whichever you choose.
- Read the checks. Fix dimension mismatches first - those rows are left out - then look at whether the vectors are unit length.
- Open the pairwise matrix to see how similar the candidates are to each other, which reveals near-duplicate chunks in an index.
Reading the results
Cosine similarity runs from -1 (opposite) through 0 (unrelated directions) to 1 (same direction) and ignores length. Many text embedding models produce mostly positive similarities, so an absolute value like 0.8 means little until you compare it with other pairs from the same model.
Dot product equals cosine multiplied by both lengths. For unit-length vectors the two are identical; for unnormalised vectors a long vector can outrank a closer one, which is sometimes intended (length can encode popularity or confidence) and often a bug.
Distances are the other way round: lower is closer. For unit vectors, squared Euclidean distance is 2 - 2 x cosine, so all three give the same order.
Worked example: why normalisation changes the winner
Load the unnormalised example. The query is (1, 0, 0). The candidates are (0.5, 0, 0), (10, 0, 0), (8, 8, 0), (0, 1, 0) and (-1, 0, 0).
By cosine the two same-direction vectors tie at 1, the diagonal scores 0.7071 (45 degrees), the orthogonal one 0 and the opposite one -1. By dot product the order changes: (10, 0, 0) scores 10, the diagonal 8, and the short same-direction vector only 0.5, below a vector 45 degrees away. By Euclidean distance the short vector is closest at 0.5, then the orthogonal one at 1.414 and the opposite one at 2, while the long same-direction vector is 9 away and the diagonal 10.63.
Press Normalise and all three metrics agree again: cosine and dot give identical scores, and Euclidean distance becomes 0 for both same-direction vectors.
Formulas and scoring rules
- Dot product
a . b = a1 b1 + a2 b2 + ... + an bn- Norm (length)
|a| = sqrt(a . a)A vector is treated as unit length when | |a| - 1 | <= 0.001.- Cosine similarity
cos(a, b) = (a . b) / (|a| x |b|)Undefined when either vector is all zeros.- Euclidean distance
d(a, b) = sqrt( sum (ai - bi)^2 )For unit vectors d^2 = 2 - 2 cos(a, b).- Manhattan distance
d1(a, b) = sum |ai - bi|- Angle
theta = arccos(cos(a, b)) in degreesScores are shown to 4 decimal places; nothing is rounded before ranking.
Which metric should an index use?
Use the metric the embedding model was trained for. Most text embedding providers return unit-length vectors and document cosine similarity; with those vectors, dot product gives the same ranking and is cheaper, which is why many vector databases default to inner product on normalised vectors.
If your vectors are not normalised, decide on purpose. Dot product lets length carry meaning; cosine throws it away. Mixing vectors from two models, or from the same model with different settings, is never meaningful - the dimension check catches the obvious case, but two 1,536-dimension models still live in different spaces.
Limitations: what the result does not prove
- It does not create embeddings. Paste vectors produced by your own model or API; comparing vectors from different models gives numbers but no meaning.
- A similarity score is not relevance. It shows where one model placed two texts, and good thresholds differ between models - calibrate on pairs you have labelled.
- It ranks exhaustively (exact search). A vector database using an approximate index such as HNSW may return a slightly different top list.
- Limits: 2,000 vectors, 8,192 dimensions and 2,000,000 numbers in total; the matrix shows the first 60 candidates.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
Frequently asked questions
How do I calculate cosine similarity between two embeddings?
Multiply the vectors element by element and add the results to get the dot product, then divide by the product of their lengths. The result is 1 for the same direction, 0 for perpendicular vectors and -1 for opposite ones. Paste both vectors here to get it with the working.
When are cosine similarity and dot product the same?
When both vectors have length 1. Cosine divides the dot product by the two lengths, so for unit vectors it divides by one. Many embedding APIs return normalised vectors, which is why indexes often use the cheaper dot product.
What is a good cosine similarity score for embeddings?
There is no universal threshold. Each model has its own range; some rarely go below 0.6 even for unrelated texts. Label a few dozen pairs as related or not, look at their scores, and set the threshold between the two groups for your model.
Why do I get a dimension mismatch?
The vectors came from different models, or from one model with a different output size setting. Similarity is only defined between vectors of the same length and the same model, so re-embed everything with one configuration.
Should I normalise my embeddings before storing them?
If you rank by cosine, normalising once at write time lets the database use dot product, which is faster and gives the same order. Keep the raw vectors only if their length carries information you want the ranking to use.
Can I paste an OpenAI embeddings API response directly?
Yes. A response with a data array of objects carrying an embedding field is recognised, as are arrays of arrays, id-to-vector maps, lists of objects with id and embedding, and plain labelled lines.
Last reviewed by the A2Z.Tools team against the sources listed above.
