An embeddings API alternative that costs nothing per token
Embeddings are the workload where a hosted bill grows quietly: you re-embed a corpus, you re-embed it again after a chunking change, and none of it needed a frontier model. The open encoders people actually benchmark against — all-MiniLM-L6-v2, bge-small-en-v1.5, mxbai-embed-large — have ONNX exports small enough to run in a browser, from 23 MB upward. This page runs them on your GPU and hands back the raw vector, so you can build semantic search or a RAG index without a key, a quota or a per-token rate.
At a glance
- What replaces it
- all-MiniLM-L6-v2, bge-small-en-v1.5, mxbai-embed-large
- Where it runs
- Your GPU, in the browser, via WebGPU
- Cost per token
- Nothing after the one-time model download
- API key
- Not needed — there is no API to call
- Text transmitted
- None
- Model stability
- Pinned: the weights you cached cannot be changed under you
- Honest limitation
- Lower throughput than a server, and small encoders score below the largest hosted models
Where the hosted API is clearly better: throughput and ceiling. A server embeds millions of chunks far faster than a laptop, the larger hosted models score higher on retrieval benchmarks than a 23 MB encoder, and they handle longer inputs per call. For a large production index, use a server — quite possibly running one of these same open models.
Where local wins: everything about the first mile. Prototyping costs nothing, so you can try four chunking strategies instead of one. Sensitive corpora never leave the device. And an embedding model you download is pinned forever, which matters more than it sounds: a hosted model that is updated or retired invalidates every vector you have already stored, because vectors from two model versions are not comparable.
The choice between them is mostly dimension and download. all-MiniLM-L6-v2 gives 384 dimensions for 23 MB and is the sensible default for a first index; bge-small-en-v1.5 is a stronger retrieval model at a similar size; mxbai-embed-large is the largest and highest-quality option here and costs a much bigger download. Whatever you pick, embed queries and documents with the same model — mixing them produces vectors that are numerically fine and semantically meaningless.
openai embeddings alternativefree text embeddingsembeddings without api keyall-minilm-l6-v2 browserbge small embeddings localfree vector embeddings for raglocal embedding modelsentence embeddings in browserprivate embeddingstext-embedding-3-small alternative
Frequently asked questions
Are these vectors compatible with the ones I already have?
Only if they came from the same model. Embeddings are model-specific: a MiniLM vector and an OpenAI vector describe different spaces and cannot be compared or mixed in one index. Switching models means re-embedding the corpus.
How many dimensions do I get?
384 for all-MiniLM-L6-v2 and bge-small-en-v1.5, 1024 for mxbai-embed-large. Smaller vectors mean a smaller index and faster search; larger ones usually retrieve a little better.
Can I embed a whole corpus here?
You can embed as much as you like — there is no quota — but a browser tab is not a batch pipeline. For a large corpus, run the same ONNX model server-side or in Node; the vectors are identical because the model is.
Is it good enough for real retrieval?
For most application-sized corpora, yes — MiniLM and BGE are the models a lot of production search quietly runs on. The largest hosted encoders do score higher, and the gap shows up most on specialised or multilingual material.
Is my data uploaded to a server?
No. The model weights are downloaded from Hugging Face to your browser once, and every inference after that runs on your own GPU through WebGPU. Your text, images and audio are never sent anywhere — hjLabs.in has no inference server and no way to see your input.