wttr.in: a curl-first weather service and the Go server behind it
:partly_sunny: The right way to check the weather
At a glance
- What is it?
- wttr.in turns a weather lookup into an HTTP request whose response is formatted for the client that asked for it. The repository is a Go service, not a library, and its design assumes you are happy reading a forecast in a terminal or parsing JSON.
- Who is it for?
- wttr.in is worth adopting if you want weather inside a shell, a tmux status line or a script, and you are content to depend on someone else's instance or run your own Go service. It is the wrong tool if you need a guaranteed uptime contract, a documented JSON schema with versioning, or a library you can call in-process; the public instance is a free service with no stated SLA, and the README points to wego as the original wrapper rather than promising API stability.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What wttr.in solves, and for whom
Most weather APIs return structured data and leave presentation to you. wttr.in inverts that. The README describes it as a console-oriented weather forecast service that supports terminal-oriented ANSI sequences for console HTTP clients such as curl, httpie or wget, HTML for browsers, and PNG for graphical viewers. The default interaction is a single command with no API key, no SDK and no JSON parsing: curl wttr.in prints an ASCII art forecast for your approximate location. The audience is therefore narrow and specific. People who want weather in a shell prompt, a tmux status bar, a WeeChat buffer or a one-line script. The README states the one-line format is convenient for exactly those cases, and gives curl wttr.in/Nuremberg?format=3 returning a line like Nuremberg with a condition glyph and a temperature. There is a second audience: anyone who wants a self-hosted weather endpoint they control, since the repository includes installation instructions for running the service yourself.
How the server decides what to render
The mechanism visible in the README is content negotiation by User-Agent. ANSI and HTML are selected based on the User-Agent string, so curl gets colourised terminal output and a browser gets a page. Everything else is opt-in through the URL. Appending .png forces the PNG renderer, and options for that mode are separated with underscores instead of question marks and ampersands, so wget wttr.in/Paris_0tqp_lang=fr.png is valid while the same options in a normal query would use ? and &. Plain text is forced with ?T, and ?d restricts output to glyphs available in standard console fonts such as Consolas and Lucida Console. That last flag is a real constraint rather than a nicety: the default ASCII art uses box-drawing characters that some terminal fonts render as boxes or question marks. The location part of the path is flexible. A city name, a three-letter IATA airport code such as muc or ham, an IP address, or a domain prefixed with @ are all accepted, and the README shows that mountain names and landmarks resolve too, printing a Location line with coordinates. That resolution step is a geocoding lookup in front of the forecast, and it is the part most likely to surprise you.
Getting a forecast: the actual commands
The smallest useful invocation is curl wttr.in, which returns the report for your current location based on your IP address. Naming a place is a path segment: curl wttr.in/London, curl wttr.in/Salt+Lake+City, curl wttr.in/Eiffel+Tower. Units are chosen by origin, USCS for queries from the USA and metric elsewhere, and overridden with ?u, ?m or ?M, where the capital M means metric with wind speed in metres per second. Multiple options are concatenated without delimiters for one-letter flags, and joined with & for long options that take values, so curl 'wttr.in/Amsterdam?m2&lang=nl' is the documented form. Machine-readable output comes from format=3 or format=4 for one-line results, and from the JSON format for scripts. Batch queries are supported two ways: colon-separated locations such as Nuremberg:Hamburg:Berlin, or brace expansion in the shell, curl -s 'wttr.in/{Nuremberg,Hamburg,Berlin}?format=3'. Custom one-line layouts use percent notation, with c for the weather condition and C for the condition text as the first documented placeholders. The full list is on the /:help endpoint, which the README tells you to fetch with curl wttr.in/:help.
The PNG path is where the dependencies bite
PNG output is the least self-contained part of the service. The README documents transparency as a URL option, with t for a preset level and transparency=0..255 for an exact value, and shows a compositing example using ImageMagick: convert source.jpg <( curl wttr.in/Oymyakon_tqp0.png ) -geometry +50+50 -composite target.jpg. That example is also a warning about what the server needs. Rendering text into an image requires fonts and an image pipeline on the host, and the README does not enumerate them. If you self-host and only care about terminal output, this is the component you can most reasonably leave untested. If you do care, the transparency option exists specifically so the PNG can be overlaid on a photograph, which means partial alpha is a supported case rather than an edge case. The README also points to wttr-switcher as a way to embed a widget in an HTML page, and cites a real deployment at feuerwehr-eisolzried.de, but that widget is a separate project by a different author, not something this repository maintains.
Where the data comes from, and why that matters
The README opens by saying wttr.in was originally a wrapper for wego, a terminal weather client, built to demonstrate console-oriented services. It does not document which upstream weather provider the current service queries, nor how often forecasts are refreshed, nor what happens when a provider fails. That is the largest gap in the supplied material, and it is not a documentation oversight you can work around by reading the code quickly: it determines whether self-hosting gives you independence or just moves the dependency. It also explains why the project is better understood as a formatting and geocoding layer than as a weather data source. The value it adds is the presentation, the URL grammar and the location resolution, not the forecast itself. If you need a contractual data source with a stated update cadence, this is the wrong layer to adopt.
A real alternative, and the actual difference
wego, the project wttr.in started as a wrapper for, is the obvious comparison. The approach differs at the point of deployment. wego is a client you install and run locally; it talks to a weather backend from your own machine and draws the forecast in your terminal. wttr.in is a server. You send an HTTP request and it renders the response, which means the rendering happens somewhere else and the output format is chosen by the request rather than by your local configuration. That distinction has practical consequences. With a local client, no third party sees which locations you look up, and there is no service that can rate-limit you. With wttr.in, the convenience of curl wttr.in from any machine with no install is paid for by that request going to someone else's server. The two are not competitors so much as different placements of the same idea, and the README's own framing acknowledges the lineage rather than hiding it.
Self-hosting cost and the Apache-2.0 terms
The repository is licensed Apache-2.0, which permits commercial and private use, modification and redistribution, and includes an explicit patent grant. It also requires that you retain the licence and notices, and state significant changes if you redistribute a modified version. That is a summary of the licence text, not legal advice. On operating cost, the material supports only a limited assessment. The service is written in Go, which the repository metadata confirms as the primary language, and the README provides installation instructions, so a self-hosted instance is a single service rather than a cluster of components. The recurring cost is not the binary. It is the upstream weather API the server queries, the geocoding lookups for each named location, and, if you enable PNG output, the fonts and image libraries on the host. The README does not state rate limits, caching behaviour or memory requirements, so any capacity estimate would be guesswork. The public instance at wttr.in is described in the README as handling tens of millions of queries daily, which tells you the software scales but says nothing about what a small deployment needs.
What to check before you depend on it
Two failure modes are visible from the documentation alone. The first is location resolution. Because a path segment can be a city, an airport code, an IP address, a domain with @, or a landmark, ambiguous names can resolve somewhere you did not intend, and the README's own examples show the resolved Location line printed beneath the forecast precisely so you can catch this. The second is font rendering in the default ANSI mode, which is why ?d exists. Neither is fatal, but both mean you should pin your queries to unambiguous identifiers rather than free text if the output feeds anything automated. The JSON format is the right target for scripts, and the README lists it alongside Prometheus metrics, which suggests the maintainers expect machine consumers. What the material does not tell you is whether that JSON has a stable schema across releases; the release metadata supplied here is empty, so there is no changelog to check. Verify that against the live endpoint before you write a parser around it.
Editorial conclusion
wttr.in is worth adopting if you want weather inside a shell, a tmux status line or a script, and you are content to depend on someone else's instance or run your own Go service. It is the wrong tool if you need a guaranteed uptime contract, a documented JSON schema with versioning, or a library you can call in-process; the public instance is a free service with no stated SLA, and the README points to wego as the original wrapper rather than promising API stability. Before you build on it, verify three things against your own deployment: which upstream provider the server is configured to query, whether the PNG renderer works without a full set of fonts and libraries, and how the location lookup behaves for the place names you actually care about.
Community notes