Methodology

What this site is built from, what was fetched and when, what was calculated, and what could not be obtained. If a number appears anywhere on TideCurve and is not traceable through this page, treat it as a bug and tell us.

Sources

NOAA data is a work of the US government and in the public domain. TideCurve is not affiliated with NOAA, and NOAA does not endorse this site.

The exact requests

Station metadata came from two listings and a per-station lookup:

https://api.tidesandcurrents.noaa.gov/mdapi/prod/webapi/stations.json?type=tidepredictions&units=english

https://api.tidesandcurrents.noaa.gov/mdapi/prod/webapi/stations.json?type=waterlevels

https://api.tidesandcurrents.noaa.gov/mdapi/prod/webapi/stations/{id}.json?expand=details

Stored predictions came from one request per station, with the date range varying by station (see the coverage table below):

https://api.tidesandcurrents.noaa.gov/api/prod/datagetter?product=predictions&datum=MLLW&station={id}&time_zone=lst_ldt&units=english&interval=hilo&format=json&begin_date={start}&end_date={end}

The live refresh your browser attempts, and the request the printable tool builds, use the same endpoint with begin_date and end_date moved to the dates you are looking at. The tool prints the URL it used on the page.

Daylight saving time, handled once

Tide times are the easiest thing on a site like this to get wrong, so the handling is deliberately boring. NOAA is asked for local time with daylight saving already applied. The build never parses those timestamps into a Date with a time zone, never converts them, and never re-formats them into another zone: it splits the string into hours and minutes and prints them. A timestamp of 2026-10-17 16:39 is printed as 4:39 p.m., and that is the clock time at the station on that date.

Two consequences worth knowing. First, on the two days a year when clocks change, local clock time is not a continuous axis, so the curve on those days is drawn against the clock and not against elapsed time. Second, if you request GMT in the printable tool, the times are GMT and the page says so in the caption — the tool never relabels one zone as another.

What is measured and what is drawn

Only two kinds of numbers appear on this site.

• NOAA values, printed verbatim. Every time and height in every table is the string NOAA returned, unrounded. A height of 8.15 is printed as 8.15, not 8.2.
• Derived values, all from those numbers. Mean range, largest and smallest range, the gap between successive high waters, and the counts of highs and lows are arithmetic on NOAA's extremes, computed in src/js/tide.js. Mean range here means the average absolute height difference between one extreme and the next within the stored window — it is not NOAA's published mean range datum for the station, which is computed over a 19-year tidal epoch.

Which stations get a page, and why 31

A station page exists only where both of these were true on 2026-10-17: NOAA's metadata API returned a record for the station, and the predictions endpoint returned high and low waters for it. 31 stations cleared both. Nothing is interpolated between stations, and no page is generated for a town, a beach or a ZIP code, because a prediction belongs to the station it was computed for.

Distances in the "nearby stations" lists are straight-line approximations from the stations' own coordinates, rounded to whole miles. They are there to help you pick a closer station, not to describe a route.

How a static page avoids going stale

A tide page that renders "this week" into static HTML is wrong a week later, and the stale copy is what search engines keep. Four things prevent that here.

• Tables are labelled by calendar month, not by "this week". A table headed November 2026 is correct for every day of November, so it does not rot between builds. Where stored predictions cover only part of a month, the heading says so — October 17–31, 2026 — and a line above the table repeats it.
• Predictions are stored per station and far ahead. Tide predictions are astronomical and NOAA publishes them years in advance, so a stored range is not a snapshot of the past: it is correct for its whole span. Each station has its own file at /data/tides/s{id}.json, so a page loads only its own predictions.
• Today's week is chosen in your browser, from that stored file. The curve and the next-high/next-low readout are re-selected client-side for the current date, using data served from this site. That needs no third-party request, so the live NOAA call is now only an optional freshness check rather than something the page depends on.
• The build refuses to publish an expired range. scripts/check-coverage.mjs fails if any station's stored predictions end before today, and warns when a station has under a fortnight left. A station whose range has passed is also marked noindex and carries a visible notice.

The week drawn into the HTML is always labelled with its own dates, so even with JavaScript disabled the page never implies it is showing the current week when it is not.

Stored coverage by station

Coverage differs by station because of a limitation in the tooling used to collect it, described under what could not be obtained. Every value below was fetched from NOAA and stored exactly as returned.

Re-running node scripts/fetch-tide-samples.mjs refreshes every station to a twelve-month horizon and rewrites both the per-station files and this table.

What could not be obtained

• Bulk prediction transfer, which is why coverage is uneven. The fetch tool available during the build would reproduce a NOAA response of roughly 180 records verbatim, but refused to reproduce longer ones, summarising them instead — and the refusal was not deterministic, so the same request could succeed once and be summarised the next time. Summarised numbers are useless here, because this site only publishes values it holds verbatim. Five stations were filled to 45 days or more before that limit bit; the rest hold the seven days that were collected first. Nothing was estimated, interpolated between stations, or carried over from one station to another to paper over the gap. The refresh script has no such limit: run on a machine with ordinary network access it fetches twelve months for all 31 stations in one pass.
• The full station list. NOAA's tide prediction station listing holds about 3,500 stations in one response, and the fetch used during the build truncated it partway through Maine. New Hampshire and Massachusetts stations were therefore taken from the water level station listing and from per-station lookups, and each was confirmed by requesting predictions for it. This is why the list is a regional pilot rather than a national one.
• Stations outside New England named in the keyword research. Myrtle Beach, Murrells Inlet, Isle of Palms and Surfside Beach in South Carolina and Port Aransas in Texas sit past the truncation point in the listing. Their station IDs were not guessed, so they have no pages. They are the first thing to add once the full listing is fetched server-side.
• Rye and Ogunquit. Two keyword targets name towns with no NOAA tide prediction station of that name in the data retrieved. The nearest verified stations are Fort Point and Jaffrey Point in New Hampshire and Wells in Maine. No NOAA station has been relabelled after a town it is not named for, because a reader who trusts the label would be reading predictions computed somewhere else.
• CORS confirmation. Whether api.tidesandcurrents.noaa.gov sends an Access-Control-Allow-Origin header could not be verified with the tool used at build time, so the browser refresh is written as an enhancement: the stored sample is already on the page, and a blocked request changes nothing except the status line.
• Tidal currents. NOAA publishes current predictions as a separate product with separate stations, and its FAQ is explicit that "tide predictions and tidal current predictions are generated separately". No current times are shown or inferred here. The high tide vs slack tide guide explains why that distinction matters more than it sounds.

What this site will not say

Predicted tide heights cannot support claims about safety or success, so TideCurve does not make them. There are no best-fishing-time ratings, no swimming or wading advice, no clearance or draft guidance, and no "safe to cross" windows. Predictions are astronomical, and NOAA's own FAQ states that it "cannot predict the effect that wind, rain, freshwater runoff" have on the water level. For conditions, use the forecast and the observed water level, not a prediction made a year in advance.

Reproducing this

The data files carry their own provenance blocks: src/_data/stations.json names the listing each station record came from, and src/_data/samples.json carries the exact request template, the coverage window and the retrieval date. Both are served at /data/ for the client-side code. Re-running scripts/fetch-tide-samples.mjs with a list of station IDs rebuilds the sample and stamps a new retrieval date.

See also about this site and the station list.