remix logo

Hacker Remix

Show HN: Uncurl.dev – Convert curl commands to a shareable, executable UI

115 points by darubramha 1 week ago | 59 comments

Hey HN,

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)

ajnin 1 week ago

Hum I'm definitely not the target for this but I don't see the value to obfuscate all the info in an UUID, I'd have kept things simple and stored things into an URL fragment, that way it's possible to operate client-side only and nothing gets leaked to a server I don't know much about like headers or whatever tokens or API keys could be passed in an URL.

themanmaran 1 week ago

I see a fair bit of utility here. We have an API product, and (despite having pretty clear docs) I almost always have to send people curl requests they can copy and run.

So I see this as similar to having a sandbox built into your docs page. Except I can customize a request and send it directly to a user. The only missing piece is the authentication part. Since I wouldn't want to embed an api key in this link.

darubramha 1 week ago

Totally with you on that—your use case is exactly what I had in mind when I built uncurl.dev.

I kept finding myself sending curl requests in Slack or email, and it felt clunky—especially when non-devs or support teams needed to test something quickly. uncurl.dev started as a way to make that share-and-execute process more visual and frictionless.

For the auth part—embedding API keys in payload is a no-go in most cases. For now, sending out auth headers separately for them to fill in themselves is what I did within my workplace.

I'm exploring a couple of ideas to help with this:

Team-scoped secrets: For logged-in users or teams, saving common auth headers that aren’t part of the shared link.

One-time, encrypted secrets: The link works once and destroys the sensitive payload after execution.

aae42 1 week ago

could also just do the request in javascript instead of needing a (presumably hosted) sandbox

TheDong 1 week ago

curl supports many things javascript doesn't. Like http proxies, tls versions, and half the other flags

ultrafez 1 week ago

There are many types of request that cannot be made with client-side JS alone, but for those that can, the ability to send those requests client-side would be handy.

markerz 1 week ago

I think that 99.9% of CURL commands are copied from Chrome/Firefox's network inspector and are the simple "client-side JS" types.

I also think it's weird to be so willing to let people run arbitrary CURL commands from your platform, without any billing or account verification. It feels ripe for abuse.

jasir 1 week ago

Even for commands that use the subset of cURL features that fetch supports, most requests to other domains (cross origin requests) wouldn't work anyway because the responses won't have the CORS[0] headers to allow being accessed from arbitrary websites. So running it client side would be infeasible for most requests.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

darubramha 1 week ago

Exactly — this was one of the core constraints I ran into early on.

CORS was a blocker for client side requests, I have a separate branch where this is integrated, maybe will add it alongside server side execution to let the person creating the curl decide whether they can execute on browser or server side.

markerz 1 week ago

Hey OP, your DELETE curl endpoint is unauthenticated! I can't DM you on HN and there's no contact on your website, so sorry for the public security disclosure. :(

mzronek 1 week ago

That's part of the vibe in vibe coding.

reassess_blind 1 week ago

V.I.B.E - Very Insecure Backend Endpoint

darubramha 1 week ago

Hey, thank you so much for catching this and calling it out , will take this up and fix it!

Really appreciate you taking the time to look and let me know (even if it had to be in public). I have added a github repo for filing bugs (https://github.com/uncurl/uncurl-support) in the docs page :)

treesknees 1 week ago

This is why in our codebase we have a rule to not use short options/flags for called commands like curl. And if there is only a short option available, it must be explained in a code comment.

xrisk 1 week ago

Why do you call curl via the binary instead of using libcurl?

treesknees 1 week ago

As others stated, shell scripts and some other automation that have to call the cli tool directly, or where we need to build out the cmd and execute it on a remote node.

We use libcurl and pycurl where it makes sense. This rule for cli options extends to other binaries as well, some that don’t offer libraries like curl does (think closed source firmware tools or ancient homegrown cli tools.)

markerz 1 week ago

Docker files too, basically just bash scripts with a different syntax

notpushkin 1 week ago

Bash scripts?

trollied 1 week ago

Flagged this because it is a security clusterfuck.

darubramha 1 week ago

Fair. I appreciate the honesty — even if it's a bit brutal :)

Security is a top priority for this project, and I'm actively working to tighten things up. This initial version was launched to validate the concept, and admittedly, there were oversights (including an unauthenticated DELETE endpoint that was highlighted).

If you're open to it, I'd love to learn more about what you'd want to see from a security standpoint in a tool like this. I'm building in public and happy to be corrected where needed.

Thanks again for keeping things real.