[HN Gopher] Show HN: Uncurl.dev - Convert curl commands to a sha...
___________________________________________________________________
Show HN: Uncurl.dev - Convert curl commands to a shareable,
executable UI
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)
Author : darubramha
Score : 107 points
Date : 2025-04-07 04:37 UTC (1 days ago)
(HTM) web link (uncurl.dev)
(TXT) w3m dump (uncurl.dev)
| h1fra wrote:
| Interesting. Default behavior could be improved. I blindly pasted
| a curl, except showing my curl it didn't make any headers
| modifiable. It also didn't redacted the Authorization header.
| Also there is no way to delete a page.
| serial_dev wrote:
| Whether redacting the auth header is the best choice can be
| determined on a case by case basis, so I don't think it should
| redact by default. A big scary warning would definitely make
| sense, though!
| byearthithatius wrote:
| Exact same thing happened to me. Had to reset my HN user cookie
| because accidentally pasted my downvote curl command.
| markerz wrote:
| FYI, you can delete anyone's CURL (including your own if you
| were unauthenticated) with the following curl:
|
| https://uncurl.dev/curl/78ab4bf5-34e8-45a0-b3b1-32dd6aa7e360
|
| or this command curl -X DELETE "https://uncur
| l.dev/api/curls?id=051606b5-49c8-4f14-9689-4d424f71d331"
|
| Looks like deletes are unauthenticated.
| darubramha wrote:
| Haha love that you shared the curl with the uncurl.dev url!
|
| Yes, delete is unauthenticated as highlighted, will be
| working on a fix for this. And you can delete any API if it
| is created as a logged in user.
| niek_pas wrote:
| Looks cool! One bug I found:
|
| `curl www.google.com` works using 8.7.1 on macOS, but I get
| "Please enter a valid curl command" on your website.
| darubramha wrote:
| :) the curl command parser expects some flags of GET, POST,
| stupidly overlooked, will get it fixed!
| ajnin wrote:
| 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.
| aae42 wrote:
| could also just do the request in javascript instead of needing
| a (presumably hosted) sandbox
| ultrafez wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| TheDong wrote:
| curl supports many things javascript doesn't. Like http
| proxies, tls versions, and half the other flags
| themanmaran wrote:
| 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 wrote:
| 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.
| Tabular-Iceberg wrote:
| It seems very particular about what curl options it supports. I
| keep getting "Please enter a valid curl command" no matter what I
| do.
|
| Maybe the only solution is to somehow extract the actual command
| line parser from curl itself.
| darubramha wrote:
| Hey that is weird, can you file a bug report here with the curl
| you were trying?
|
| https://github.com/uncurl/uncurl-support
| VWWHFSfQ wrote:
| This would be useful if it was client-side only. I only very
| rarely have curl commands to run that don't also include some
| stuff like cookies and tokens, which I'm not sending to someone's
| server so they can run curl for me.
| cgannett wrote:
| I cant even get the thing to work
| byearthithatius wrote:
| Multiple people already did and are confirming they can't even
| delete it. This website is literally a security issue itself.
| darubramha wrote:
| Hey, you can absolutely delete any curls created if done from
| a logged in user, for others it will get auto-purged in 30
| days of non-usage.
| treesknees wrote:
| 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 wrote:
| Why do you call curl via the binary instead of using libcurl?
| notpushkin wrote:
| Bash scripts?
| markerz wrote:
| Docker files too, basically just bash scripts with a
| different syntax
| treesknees wrote:
| 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.)
| polishdude20 wrote:
| Why the need for an account to execute? Are you executing the
| command on behalf of the user on your server? Is it possible to
| just do it locally in browser?
| zamadatix wrote:
| The post mentions the server is used during the optional
| execution. My guess as to why would be primarily because there
| are plenty of curl commands which are impossible to execute via
| the browser due to browser restrictions and secondarily because
| the execution is literally running curl, not trying to
| approximate the equivalent action.
|
| 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.
| VWWHFSfQ wrote:
| It actually looks like the server is used regardless. It's
| sending the full curl command to the backend even if not
| executing it.
| zamadatix wrote:
| Well yeah, it's generating short links. I mean to highlight
| the server runs curl in a sandbox against the 3rd party
| host on behalf of the user, not just that the server and
| client talk to each other as you use the page.
| darubramha wrote:
| Yes -- executions are done server-side, inside a resource-
| limited, sandboxed Docker container. That's why login is
| required: to prevent abuse, rate-limit usage.
|
| 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.
| flipperto wrote:
| While it looks good and even possibly useful, it seems to be a
| great way to leak sensitive cookies (especially since "copy as
| cURL" is so easy on the browser's network tab).
|
| 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.
| byearthithatius wrote:
| Thank you. I literally already accidentally uploaded a cookie
| that I now need to reset because the website doesn't let me
| delete the curl -_-
| ustad wrote:
| Hey, that looks great.
|
| Could you describe more about the docker sandbox that you have? I
| am especially interested in the network restrictions.
| darubramha wrote:
| The sandbox is a lightweight Alpine-based container, it runs as
| a non-root user for security, it has minimal dependencies
| installed (curl, bash, coreutils)
|
| 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.
| ustad wrote:
| Thanks for the details!
|
| 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?
| benoitg wrote:
| The Jetbrains suite of IDEs have this handy feature : if you copy
| a curl command into an HTTP scratch file, it is automatically
| converted to the HTTP equivalent, which is IMHO much more
| readable.
|
| Your project looks very cool though, and expands on the share
| aspect of the Jetbrains feature, very interesting!
| _kidlike wrote:
| my thoughts exactly!
|
| Lately I feel like a lot of people think they are finding gaps
| around developer experience, but it's only because they don't
| know the right tools that already exist...
| hk1337 wrote:
| Paw (Now RapidAPI) has a nice feature that generates a http
| request. The curl plugin and http plugin are the main ones I
| use but there's several others to generate the code in other
| languages too.
| darubramha wrote:
| Appreciate the kind words--and the comparison!
|
| uncurl.dev kind of grew out of that same spirit, but with the
| goal of making the output shareable and executable in a
| browser, especially for folks who might not have an IDE set up
| or are outside the usual dev loop (PMs, etc.)
| fitsumbelay wrote:
| This is a pretty cool project.
|
| 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
| darubramha wrote:
| You didn't miss anything in the docs. Right now uncurl.dev only
| supports http/https (and technically ftp, though it's
| untested). Protocols like dict://, smtp://, etc. aren't parsed
| or handled correctly yet, which is why you're seeing that
| "invalid URL" error.
|
| I hadn't actually considered dict:// usage, I see the bug
| report as well, thanks, will see if I can include it.
| lenkite wrote:
| Feels like a security nightmare - this is far better distributed
| as a local desktop UI rather than one hosted.
| byearthithatius wrote:
| It 100% is because he just keeps your curl and you can't even
| delete it. He just keeps it forever for himself even if you
| made a whoops. Already accidentally uploaded my HN user cookie
| and had to reset it. JFC.... -_-
| thomasfromcdnjs wrote:
| lmao I did similar.
| darubramha wrote:
| I have implemented auto-purge all curls that are created
| without login will get auto deleted after 30 days of non-
| usage.
|
| You can absolutely delete your curl if you have created as a
| logged in user.
| byearthithatius wrote:
| I already accidentally uploaded a cookie that I now need to reset
| because the website doesn't let me delete the curl -_-
| markerz wrote:
| Definitely reset your password/account even if you can delete
| it from their website. Otherwise, you are trusting a stranger
| with no privacy policy or reputation.
| byearthithatius wrote:
| Great point, true!
| dwrowe wrote:
| There is both this post about not being able to delete a curl,
| and other posts about being able to delete curls
| unauthenticated. Looks like you should be able to issue a
| DELETE curl request, to delete your curl.
| darubramha wrote:
| You can delete the curl request if created from a logged in
| account.
|
| Non-logged in curls are auto purged after 30 days.
| byearthithatius wrote:
| This is just waiting for people to leak cookies oh my lord....
| trollied wrote:
| Flagged this because it is a security clusterfuck.
| darubramha wrote:
| 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.
| markerz wrote:
| 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 wrote:
| That's part of the vibe in vibe coding.
| reassess_blind wrote:
| V.I.B.E - Very Insecure Backend Endpoint
| darubramha wrote:
| 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 :)
___________________________________________________________________
(page generated 2025-04-08 23:02 UTC)