A personal weather website fails in the browser as often as it fails at the logger. Invalid HTML, mixed CSS, a coordinate typed in the wrong notation, a color that hides “Offline”—those are operator problems, and they are not solved by downloading another station-software plugin. The historical URL /webtools.php was a hub of browser and web tools for people who published stations: validators, inspectors, converters, and similar checks you run against pages and metadata. It was not a warehouse of ZIPs, and it was not the PHP script catalog.
This article is distinct from /scripts.php, which explains the shared PHP tooling layer (parsers, graphs, include templates) as an engineering problem. Here the subject is the operator’s web workbench: tools that inspect or transform what the browser and the metadata already contain. Recovered lists of graphics editors, FTP clients, and affiliate download links are not republished. Those packages had unclear redistribution rights and are not TNET products.
Historical context
Station operators in the 2000s were accidental webmasters. They uploaded HTML from Weather Display, hand-edited includes, pasted banner tags, and then stared at a page that looked right in one browser and collapsed in another. A “web tools” page on a weather site was a teaching index: where to validate markup, how to see CSS boxes, why a screen-capture utility is not a sensor, which converter to use before you submit latitude to a map.
The historical TNET page mixed that hub with a software inventory (vector drawing, capture, editors, backup). The inventory is the wrong modern article. It ages into dead affiliate URLs and version folklore. The hub is the right article: what jobs an operator should run in the browser before trusting a published page as an observation product.
A sidebar of “random weather facts” on the recovered page was not a tool. It is omitted.
Why this hub is not a download dump
Three failures turn a tools index into a junk drawer.
Confusing authoring software with observation tools. A drawing program can make a banner. It cannot validate that the banner’s rain total matches the packet. Listing it beside a markup validator teaches the wrong lesson.
Shipping binaries. Even when a utility was freeware, this restoration does not rehost it. Licenses, malware risk, and abandoned installers are why a hub should name the job and point at a current official service when one exists.
Duplicating /scripts.php. PHP parsers and graph snippets are server programs that read uploaded station files. Browser validators do not. If a link belongs on the scripts hub, it does not belong here as a second download list.
The test for this URL: would the operator use the tool in a browser, or on a file the browser can open, to check pages, coordinates, or accessibility—without installing station software? If yes, it is in scope. If the tool is a PHP package to copy into web root, it belongs on the scripts article.
The jobs the hub should name
Markup and CSS validation
A conditions table that does not parse as HTML will be repaired differently by every browser. Column headers can vanish. Units can attach to the wrong cell. The W3C Markup Validation Service is the durable public check for that class of error (last checked 13 August 2026). CSS validation is the sibling job: a layout that hides a timestamp on a narrow screen is a data-quality bug, not a taste dispute.
Validation does not prove the temperature is right. It proves the document can carry the temperature. That is the include contract’s presentation layer, and it is why a restyled networked conditions module still needs a validator pass.
Accessibility as a publication requirement
If a gauge is only a color, or a trend is only an unlabeled arrow, part of the audience never receives the observation. Accessibility checkers exist to catch missing text alternatives, contrast failures, and heading chaos. Standards language belongs to WCAG and, in U.S. federal contexts, Section 508—not to a weather hobby page inventing a score. The hub’s job is to say: the observation must survive without the graphic. A station that already publishes a text table is closer to that requirement than a station that publishes only a Flash needle.
Coordinate and unit conversion
Map networks and MADIS ingest need a latitude and longitude that mean what the operator thinks they mean. Decimal degrees versus degrees–minutes–seconds, sign errors, and 0.01° mistakes are metadata failures that look like weather. The converter article on this host is /latlong-convert.php. Official geodetic conversion for survey-grade work is NOAA NGS NCAT, not a weather-site snippet (NGS NCAT).
Unit conversion (Fahrenheit/Celsius, inches/millibars, miles per hour/knots) is the same class of tool: it is a check, not a new sensor. Printing both unit columns side by side is how you catch a station that is in °F while a partner include assumes SI.
Inspection, not capture
Browser developer tools—element outlines, computed CSS, network waterfalls—show whether a “live” image is a cached GIF, whether a table cell is empty, whether a script failed. That inspection is a first-class operator skill. Screen-capture utilities document a bug; they do not substitute for reading the packet. A hub may mention capture as a way to record a failure for later. It should not rank a capture program as weather equipment.
Experimental versus production tools
A beta parser or a new widget is a tool, but it is not a quality-controlled observation. Label those on /experimental.php. A validator hub that quietly links a sandbox decoder without a warning will get quoted as if it were MADIS.
A practical operator sequence
Before you trust a station page, or before you announce that a restyle “changed nothing”:
- Validate the HTML and CSS of the public page.
- Confirm every numeric column still has a unit in a header or adjacent text.
- Confirm a timestamp and station ID are visible without JavaScript if you can.
- Convert and re-read coordinates if the station is going to a map or CWOP.
- Use a named-field diagnostic for compact packets (ClientRaw parser article) rather than eyeballing a dashboard.
- Keep PHP installables on the scripts hub, not on this page.
That sequence is the hub. It is a workflow, not a shopping list.
Distinct from scripts, notebooks, and experimental code
| URL | What it is | What it is not |
|---|---|---|
| /webtools.php (this page) | Browser/web checks and converters as a hub | A download catalog |
| /scripts.php | PHP layer: parsers, graphs, includes | A W3C validator index |
| /wd-parser.php | Diagnostic meaning of a ClientRaw decode | A live remote-fetch form |
| /experimental.php | Why beta pages must be labeled | A second tools list |
| /latlong-convert.php | Coordinate notation and precision | A GPS replacement |
Operators who want to write PHP belong on the scripts and notebook pages. Operators who want to check a published site belong here.
Modern relevance
The named utilities on a 2000s page are gone or renamed. The jobs are not. Shipping a Vue or static site does not retire validation, accessibility, or coordinate hygiene. Connection-research and weather-research still fail first on source identity, units, and freshness—the same issues a webmaster’s workbench was built to catch.
TNET’s public note on those issues is data sources, quality controls, and methodology. How the modern service describes observed versus derived evidence is how the service works. The weather-station hub indexes the instrument and publishing articles. This URL does not install software, does not affiliate with former vendor tools, and does not expose TNET internals.
Sources
- W3C Markup Validation Service: validator.w3.org (last checked 13 August 2026)
- NOAA National Geodetic Survey, NCAT: ngs.noaa.gov/web_services/ncat/index.shtml
- TNET, Data sources, quality controls, and methodology
- TNET, Weather-station hub