Very neat! It's also possible to do this 100% statically without checking the user agent, by using alternate terminal buffers:
- `curl -L https://cole.ws` (my personal portfolio site) does this
It embeds the actual HTML inside an alternate terminal buffer (starting with `<!--\x1b[?1049h-->\r` and ending with `<!--\x1b[?1049l\x1b[3D\r`), and has the curl-able content appended to the end.
When you curl it, it still writes the HTML to your terminal, but immediately clears that buffer and writes the ANSI version to your real screen. In browsers, this ANSI stuff is hidden in an HTML comment. This is useful for static sites on GitHub pages or something.
Something like Emails ?
They can have both text and html version, its the client capabilities that determine what gets rendered like in cli mutt it will show text body, while gmail app/browser with rich documemt capability can render html
>If you were just trying to download the original HTML version of this page, add -H "X-Original: true" to the curl command to have the server respond exactly how it would've to any non-curl HTTP client.
It seems like "Accept: text/html" would be more standard
But it is really up to the author to decide what "canonical" is. I serve my blog in markdown by default and only switch to html when it is explicitly requested.
I've found a bit less fun, but similar, way to present for the CLI. `curl -L tinthe.dev` is HTML, don't see why to mess with the default.
But, I did put in `<link rel="alternate" type="text/markdown" href="/home.md" title="...">` as a hint for using `Accept: text/markdown` on the same URL. Or going to .md versions of pages. Did it in a "sprint" of optimizing for other devices, screen readers, and LLMs. It is supported on the full page, posts included. Same point as the draft preview, less color.
Gets you 95% of the way there. The agents can take the .md and skip the layout. And I think `curl -LH "Accept: text/markdown" tinthe.dev` is pretty readable, too.
Wait does this suggest that there are can be vulnerabilities in viewing a website in curl? I do this sometimes, when I want to check a website that I suspect might be malicious. There have been vulnerabilities associated with ANSI control codes, so I really DON'T want those to be included in a display.
I think these are very fun and I would love to see more content you can visit with curl. I'm setting up a home chores + calendar + weather station that runs off my homeserver. I was contemplating making a plaintext version so very stupid devices could still read and display interesting data.
I have the Extended Support Release 115.17.0esr (64-bit) GNU IceCat gnu - 1.0 on my old intel mac and the nytpu.com displays fine, HN does too with hn.js blocked by LibreJS
Very neat! It's also possible to do this 100% statically without checking the user agent, by using alternate terminal buffers:
It embeds the actual HTML inside an alternate terminal buffer (starting with `<!--\x1b[?1049h-->\r` and ending with `<!--\x1b[?1049l\x1b[3D\r`), and has the curl-able content appended to the end.
When you curl it, it still writes the HTML to your terminal, but immediately clears that buffer and writes the ANSI version to your real screen. In browsers, this ANSI stuff is hidden in an HTML comment. This is useful for static sites on GitHub pages or something.
Something like Emails ? They can have both text and html version, its the client capabilities that determine what gets rendered like in cli mutt it will show text body, while gmail app/browser with rich documemt capability can render html
email clients support multipart/mixed, browsers never saw the need
1 reply →
Fun! I also did something similar with my personal website this summer:
- `curl listening.cailinpitt.com` shows what music I've been listening to recently
- `curl reading.cailinpitt.com` shows what books and articles I've been reading recently
hey that's pretty curl
[dead]
>If you were just trying to download the original HTML version of this page, add -H "X-Original: true" to the curl command to have the server respond exactly how it would've to any non-curl HTTP client.
It seems like "Accept: text/html" would be more standard
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
... and then use `text/x-ansi` as the curl version, so other text-based clients could also fetch it:
wget -O - --header='Accept: text/x-ansi' nytpu.com/gemlog/2026-03-18
See: https://www.digipres.org/formats/sources/wikidata/formats/#q...
Yeah, I like this more. I want curl/wget to get the canonical representation by default.
But it is really up to the author to decide what "canonical" is. I serve my blog in markdown by default and only switch to html when it is explicitly requested.
text/x-ansi is real? Wild
You can use whatever name you like and the “x-“ indicates it’s experimental.
An RFC exists that discourages the “x-“ naming, but it’s still very much in use in the wild.
1 reply →
I've found a bit less fun, but similar, way to present for the CLI. `curl -L tinthe.dev` is HTML, don't see why to mess with the default.
But, I did put in `<link rel="alternate" type="text/markdown" href="/home.md" title="...">` as a hint for using `Accept: text/markdown` on the same URL. Or going to .md versions of pages. Did it in a "sprint" of optimizing for other devices, screen readers, and LLMs. It is supported on the full page, posts included. Same point as the draft preview, less color.
Gets you 95% of the way there. The agents can take the .md and skip the layout. And I think `curl -LH "Accept: text/markdown" tinthe.dev` is pretty readable, too.
Wait does this suggest that there are can be vulnerabilities in viewing a website in curl? I do this sometimes, when I want to check a website that I suspect might be malicious. There have been vulnerabilities associated with ANSI control codes, so I really DON'T want those to be included in a display.
Finger lives.
https://en.wikipedia.org/wiki/Finger_(protocol)
Funny timing! I just set up wthr.dev (a domain I've had for a while) like this, modeled off of wttr.in, but with simpler output. Usage is like:
The geocoding heuristics can be a bit wonky, but it works decent.
(also I have comically strict rate limits in place, so you probably don't want to use this. it's also running out of my basement)
Also germane today a fix for curl/libcurl was released. The main vulnerability hinges upon using a malicious server to attack the client.
CVE-2026-92392
https://daniel.haxx.se/blog/2026/10/07/twenty-two-pending-cu...
FYI it works just fine on Windows if you run it from Terminal instead. As long as you don't use PowerShell mode in it.
I think these are very fun and I would love to see more content you can visit with curl. I'm setting up a home chores + calendar + weather station that runs off my homeserver. I was contemplating making a plaintext version so very stupid devices could still read and display interesting data.
> ... I'll have you know that my markup language has had an explicit markup element for emdashes since November 2022.
You mean like, — in HTML?
i hope it's not the dedicated Unicode EM DASH —
Hey, a fellow curl enthusiast :)
I made https://addr.fyi to return various information about IP addresses in plaintext.
Does it help make your website more accessible to agents browsing the web?
unlikely
Awesome! I always wanted to try browsing the web like RMS ;)
Jokes aside, RMS browses the web on GNU IceCat (Firefox fork), with the LibreJS extension on
I have the Extended Support Release 115.17.0esr (64-bit) GNU IceCat gnu - 1.0 on my old intel mac and the nytpu.com displays fine, HN does too with hn.js blocked by LibreJS
Good Browser.
Not quite the same, but shameless plug for my polyglot website with a `curl | sh` mode: https://trey.sh
It's not available on Windows :( Can't open cause I use Windows.
curl wttr.in !
[flagged]
[flagged]