RAG data residency: where the document is converted
Data residency for RAG is the place where the document is parsed and embedded, and the place the resulting passages are stored afterwards. Converting in the browser keeps the file on the device. The API processes an upload for the length of the request and returns JSONL you store yourself.
What does data residency mean for a RAG conversion?
Data residency for RAG is where the file is parsed and embedded, and where you then store the passages. The browser keeps the document on the device. The API accepts an upload for the request and returns JSONL for you to store.
Residency is a place, not a slogan
A privacy policy says what a company intends to do with a copy it has. Residency is whether that copy exists. For a RAG pipeline there are three places, and they are easy to collapse: where the file is parsed, where the passages are embedded, and where the vectors sit afterwards so questions can search them. A tool can be careful about the third and careless about the first. Conversion is the step that has to read every byte.
The browser path never makes the copy
ragconverter.com's free converter runs in the tab. Parsing, chunking, and embedding happen where the file already is. There is no upload, so there is no regional bucket to choose and no retention clock to trust. That is the residency control that survives a change of vendor terms, because the vendor never held the document. The limits are a browser's: 8 MB and 400 chunks on the free tier, more when you are signed in, and a 4 GB WebAssembly address space. Local RAG in the browser is that runtime in detail, and why convert documents locally is why the sensitive files are the ones people want converted.
The API is a hosted conversion, for the length of the request
When the job is unattended - a folder, a recording, OCR past what a tab can hold - the file is posted to /v1/convert. It is processed on the server and the response is NDJSON you keep. The API is not the index. It does not become the place you query next month. Residency after that response is wherever you load the JSONL: your own database, in the region you picked. Calling the API means you accepted a transfer for the duration of the conversion. It does not mean the service is a private region under your contract, and this site does not claim a certification in place of that choice. The contract itself is the RAG conversion API.
Storing the corpus is the step people skip
A local conversion followed by uploading the JSONL to a hosted vector database moved the text. The passages are the document, overlapping and sometimes easier to search than the original. Residency has to cover that store, the embedder that runs at question time, and the model that reads the retrieved passages. RAG with frontier models is the last of those: a small embedder can run beside the file, and a frontier model should see a few passages, not the library.
Decide per document
A public handbook can take the API. A draft contract, a patient note, or a board paper can stay in the tab, and the JSONL can stay on that machine until someone decides the store is allowed to hold it. The two paths emit the same chunk objects, so the residency choice does not fork the importer. The manifest names the embedder and any file that was skipped, which is the record you want when someone later asks where a passage came from. Both paths run on Remade with Rust libraries, one compiled for the browser and one for the server.