Extract structured data from any source

Parsing looks simple until you do it.

You write a PDF parser. Then someone uploads a scanned PDF and it breaks, so you add OCR. Then a customer submits an audio file and you need transcription with timestamps. Then a Word document arrives with its own set of quirks, and a web page hides its content behind JavaScript rendering. Each source type is a separate integration with its own failure modes and its own maintenance burden, and none of it is the thing you set out to build.

This page is for teams whose product accepts files from users or ingests content from external sources, and who are now spending more time on parsing than on the feature parsing was supposed to enable.

What you have probably already tried

The path through this is fairly consistent.

A library per format is where most teams start, and it works until the edge cases arrive. A PDF library handles clean digital PDFs and fails on scans. Tables that break across pages come out scrambled. Metadata sits in inconsistent fields. Each fix is small and none of them are the last one.

Bolting on OCR handles scans but adds a second pipeline with its own quality issues, and you now maintain a branch in your code that guesses which path a given file should take.

A transcription service for audio and video is another vendor, another SDK, another response format to normalise, and if you want timestamps aligned to text you are doing that mapping yourself.

Headless browser rendering for web pages works and is heavy, and now you are running browser infrastructure to read an article.

Each of these is defensible in isolation. Together they are four or five integrations, four or five failure modes, and a normalisation layer you wrote to make their outputs resemble each other. That layer is pure overhead: it produces nothing a user ever sees.

How Exabase handles this

Extract takes any file or URL and returns structured JSON from a single endpoint. PDFs, images, audio, video, Word documents, and web pages all go to the same place, and the API detects the content type and adapts the response.

Text comes back in chunks with location references, page numbers for documents and timestamp ranges for audio and video, so an answer built on the output can cite exactly where it came from. Every job generates a CDN-hosted thumbnail, and PDFs get a rendered version. Processing is asynchronous: poll for results, or configure a webhook and Exabase posts to you when the job completes, which is what you want when a two-hour recording takes longer than a request timeout.

The output is also already connected to the rest of the platform. Store extracted content as a Resource and it is immediately searchable through Deep Search. Point a Worker at it and updated documents get re-extracted on a schedule. There is no glue code between extraction, storage, and search, because they are the same system.

The same API, addressed by task

The endpoint is one thing, but most people arrive looking for something specific. Each of these is the same underlying extraction, documented for the job you actually have:

Documents: PDF to JSON, PDF to chunks, PDF thumbnail generator.

Media: audio to JSON, audio transcription, video to JSON, video transcription.

Images: image to JSON, image to text for OCR.

Business documents: invoice to JSON, contract to JSON, resume to JSON.

Web: website to JSON, and the free link preview API for lightweight metadata like title, description, and image, which returns instantly from a single GET request.

You learn one API and extract from anything. The full list is at tools.

Get started

The Extract page has the API detail and code examples. For processing at volume, document extraction at scale covers batching, retries, and webhooks, and the simple document extraction tool example is a working build to read. If the extracted content is destined for retrieval, making your RAG pipeline accurate picks up where this leaves off. There is a free tier to test against.

FAQs

What file types does it handle?

PDFs, images, audio, video, Word documents, and web pages, all through the same endpoint. The API detects the content type and adapts the response rather than requiring you to branch by format.

Does it handle scanned documents?

Yes. Scans go through the same endpoint as digital PDFs, so you do not need a separate OCR path or logic to decide which pipeline a file belongs in.

What does the output actually look like?

Structured JSON with text split into chunks, each carrying a location reference: page numbers for documents, timestamp ranges for audio and video. Jobs also produce a CDN-hosted thumbnail, and PDFs get a rendered version.

How do I handle long-running jobs like video transcription?

Configure a webhook and Exabase posts to you when the job completes, so you are not polling or holding a request open. Polling is available if you prefer it.

Can I get just the metadata from a URL without full extraction?

Yes, the free link preview API returns title, description, and image from a single GET request and responds instantly. Use full website to JSON extraction when you need the page content itself.

Is extracted content searchable straight away?

Yes, if you store it as a Resource. It is indexed for Deep Search on storage, so extraction and search are one flow rather than two systems you connect yourself.

What happens when a source document changes?

Point a Worker at it and updated documents are re-extracted on a schedule, so your extracted content stays in step with the source. Keeping your knowledge base current covers that pattern.