Posted by darubramha 4/7/2025
I built uncurl.dev to scratch my own itch: I kept getting curl commands in API docs, bug reports, or Slack messages and wanted a quick way to visualize, run, and debug them without firing up Postman or writing code to dissect them. It was also sometimes painful to create a test page specifically for non-tech users to consume an API. I originally vibe-coded this over a weekend just to make it easier for myself to debug API requests shared as curl commands. It slowly grew into something I found surprisingly useful in my workflow, so I decided to clean it up and share it.
uncurl.dev takes a curl command and: - Converts it into a visual representation - Lets you edit and inspect all parts of the request - Allows sharing via a unique link - (Optionally) executes it from the server, so business or non-technical users can see results
Execution is currently behind login, with a cap (5/min) to avoid abuse and manage costs. Non-logged-in users can still build and share curl commands—they just can’t execute them. The server runs each request in a Docker sandbox with strict resource/time limits (cpu, memory, timeout, no network access outside the request).
It’s not meant to replace full-featured tools like Postman or Hoppscotch. It’s more of a “CLI-to-UI bridge” for fast sharing and debugging, especially in dev workflows where curl is the starting point. Think of it like Pastebin or JSFiddle, but for curl commands.
If you’ve ever copied a curl from an API doc and wanted a cleaner way to see it or send it to someone else, I’d love your feedback.
Thanks! (You can try it without signup here: https://uncurl.dev)
I would 100% forbid its use in a company environment and I would encourage people in general not to use it for any non-trivial use case.
One thing: it's rejecting dict lookups as invalid URL, eg. `curl dict://dict.org/d:failure:fd-eng-fra`
I'm checking first here whether I missed something in the docs about not supporting DICT before I add issue to the GH repo
I hadn’t actually considered dict:// usage, I see the bug report as well, thanks, will see if I can include it.
Non-logged in curls are auto purged after 30 days.
Could you describe more about the docker sandbox that you have? I am especially interested in the network restrictions.
The container has restricted outbound access—only HTTP/S requests are allowed. It runs inside an isolated network namespace with no access to the host network or other infrastructure components. There's no inbound access, and the container can't receive unsolicited requests from the outside world.
The sandbox container can only communicate with other containers in the same network, the main application container and sandbox container are on the same network, allowing them to communicate.
Do you think there could be ways for someone to abuse the network setup you have?
For example, accessing other internet hosts or other containers in the same container network?
What happens when curl gets redirect responses?
I have a feature working to allow users browser side execution, but as others have also pointed out CORS is a big blocker for client side execution not working for all APIs.
Local execution could still be a handy feature for at least the most common basic commands though, but it'd start to have to wade into "explaining a lot to the user why this isn't really what the result might look like" territory.