EdibleText

Why we built this

Every RAG system has the same bottleneck: getting content into a format the model can actually use.

We hit this wall over and over. Build an AI product, need to ingest content, and suddenly you're stitching together three or four different services. One for PDFs. One for web pages. One for documents. Each with its own response format and failure modes. The conversion itself was never the hard part. The plumbing was.

The tools exist. Plenty of them. Open source libraries that need a GPU and a weekend of setup. Cloud APIs locked to specific ecosystems. Scraping tools that only handle URLs. Document parsers that only handle files. None of them just take whatever you have and hand back markdown.

We kept building the same glue code across projects. Normalizing responses, handling edge cases, routing different input types to different services. It was the kind of work that feels productive but isn't. All your time goes to scaffolding before you write a single line of product code.

EdibleText is the endpoint we kept wishing existed.

How it works

One endpoint. Send it a file, a URL, raw HTML, a video link, a spreadsheet. If EdibleText can process it, you get clean, structured markdown back. If it can't, you get a consistent error response. No surprises either way.

The API is the product. Authentication is straightforward. The response format is predictable. You don't need to pick the right endpoint for the right file type or configure a processing pipeline. Send the input, get markdown.

For developers, that's the whole thing. One dependency instead of five. One response format to parse.

For everyone else, there's a dashboard. Drag a file in, paste a URL, and see the converted markdown rendered in real time. Same capabilities as the API (it consumes the same endpoint on the backend). The dashboard puts a visual interface on it for people who don't need code.

What makes it different

We are not claiming to do something nobody else can do. The conversion capabilities exist across a dozen tools. Firecrawl handles web pages well. Jina Reader is dead simple for URLs. Docling does solid PDF work. Good tools.

But none of them cover everything, and the developer experience across most of them ranges from tolerable to painful. You end up picking three tools based on input type, learning three sets of documentation, handling three different response formats, and maintaining the routing logic that ties them together. Conversion is a solved problem, just not in any single tool.

EdibleText solves the experience. One endpoint that handles the routing internally so you don't have to. Clean documentation. Predictable behavior. The kind of developer experience where you read the docs once, write the integration, and forget about it.

The dashboard extends this to non-technical users. Same conversion quality, same reliability, no code required. Drop something in, see the markdown, copy or download it.

Where it's headed

The API works today. The roadmap is coverage and quality.

More input types. Better handling of the hard cases: scanned documents, complex table layouts, multi-column PDFs, handwritten text. The kind of edge cases where most tools produce garbage and developers end up doing manual cleanup. Every file type that works reliably is one less reason to reach for a second tool.

The dashboard gets smarter too. Batch processing for teams converting content libraries. Side-by-side previews showing the source and the rendered markdown. Export options that fit into existing content workflows.

The goal is simple: be the one place you send content when you need markdown back. Handle everything well and stay out of the way.