checking your browser…

1. Load modelDownloads once, then caches

2. Index textChunk + embed locally

3. SearchRank by cosine similarity

1. Pick and load an embedding model

Embedding model (ONNX, from Hugging Face)

Compute

Nothing downloads until you press that button. The weights come straight from Hugging Face to your browser and are cached by the browser afterward, so a second visit skips the download. Your text is never sent anywhere: there is no server call in this tool at all.

2. Give it a corpus

Your text (paragraphs separated by a blank line work best)

Drop a .txt or .md file here, or

Chunk size (words)

Chunk overlap (words)

Load a model first.

3. Search by meaning

Your question

Results to show

Ranked chunks

Scores are cosine similarity between the query vector and each chunk vector, on normalized embeddings, so the range is roughly -1 to 1 and higher is closer in meaning. In a real RAG setup you would take the top few chunks and paste them into a language model prompt as context. The retrieval half, which is the half people reach for a vector database to solve, is the code you just ran.

Why this tool exists

The standard advice for retrieval is to pay an embedding API per document, push the vectors into a hosted vector database, and pay again per query. For a corpus the size most small operations actually have, a handbook, a product catalog, a few hundred support answers, all three of those line items are optional. The embeddings can be computed in the browser on the visitor's own chip, and the search is a dot product over an array. This tool is the honest demonstration: the ranking you see is a plain JavaScript loop over a plain JavaScript array of vectors, with no index structure at all, because at this scale that is genuinely fast enough. The costs you can see here are the only real ones: the one-time model download and the time it takes to embed your text.