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.
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.
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.
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.
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.
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.
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.
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. :(
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 :)
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.
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.)
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.
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.
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.
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!
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!
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.)
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.
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...
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.... -_-
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
could also just do the request in javascript instead of needing a (presumably hosted) sandbox
curl supports many things javascript doesn't. Like http proxies, tls versions, and half the other flags
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.
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.
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...
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.
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. :(
That's part of the vibe in vibe coding.
V.I.B.E - Very Insecure Backend Endpoint
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 :)
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.
Why do you call curl via the binary instead of using libcurl?
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.)
Docker files too, basically just bash scripts with a different syntax
Bash scripts?
Flagged this because it is a security clusterfuck.
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.
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.
Multiple people already did and are confirming they can't even delete it. This website is literally a security issue itself.
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.
I cant even get the thing to work
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.
Hey that is weird, can you file a bug report here with the curl you were trying?
https://github.com/uncurl/uncurl-support
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.
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
Looks like deletes are unauthenticated.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.
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!
Exact same thing happened to me. Had to reset my HN user cookie because accidentally pasted my downvote curl command.
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!
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.)
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.
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...
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.
:) the curl command parser expects some flags of GET, POST, stupidly overlooked, will get it fixed!
Feels like a security nightmare - this is far better distributed as a local desktop UI rather than one hosted.
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.... -_-
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.
lmao I did similar.
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.
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 -_-
This is just waiting for people to leak cookies oh my lord....
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
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.
I already accidentally uploaded a cookie that I now need to reset because the website doesn't let me delete the curl -_-
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.
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.
Great point, true!
You can delete the curl request if created from a logged in account.
Non-logged in curls are auto purged after 30 days.
Hey, that looks great.
Could you describe more about the docker sandbox that you have? I am especially interested in the network restrictions.
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.
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?
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?
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.
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.
It actually looks like the server is used regardless. It's sending the full curl command to the backend even if not executing it.
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.