Weather routing software has quietly become as normal on board as chartplotter software, and about as varied in quality. On paper, they all promise the same thing: feed in a start, a destination, a departure window and your boat's polars, and out comes an optimized route across a GRIB field. In practice, the differences show up on day three of a passage when the wind veers earlier than forecast, your GRIB is 18 hours stale, and the router is still confidently telling you to gybe in six hours. Choosing the right tool is less about the interface and more about understanding what the engine underneath is actually doing with your data.

What routing software actually does, and what it doesn't

A weather router is an isochrone solver. It takes a wind field over time (your GRIB), a performance model of your boat (your polars), and computes the fastest theoretical path between two waypoints. That is genuinely useful, but it is also a narrow definition of "best route". The software does not know that your autopilot struggles above 25 knots true, that your genoa is tired, that your partner gets seasick on a beam reach in swell above two metres, or that the fuel dock in your fallback port closes at 18:00 on Sundays.

Before you compare products, decide what you actually want out of the tool:

  • Pure performance routing for racing or delivery work, where minutes matter and you will hand-steer or trim to hit the polars.
  • Comfort-weighted routing for cruising, where you want to avoid wave heights, wind angles or squall risk above a threshold, even if it costs six hours.
  • Tactical decision support where you are mostly interested in "should I leave tomorrow or Thursday", not the exact great circle out of the port.

Most software claims to do all three. Very few do all three well.

Polars are the input that decides everything

Every routing algorithm is only as good as the polar table you feed it. This is the number one thing most owners underestimate. A generic polar for "40-foot cruiser" pulled from a forum will give you a plausible-looking route that is quietly wrong by 10 to 20 percent on every leg. Over a 400-mile passage, that compounds into arrival times that are useless for planning tides, fuel stops or crew rotations.

Good routing software should let you:

  • Import and edit polars in a standard format (CSV, or the .pol format used by most open-source tools).
  • Apply a global performance factor (typically 0.85 to 0.95 for cruising trim with full tanks and a dodger).
  • Define separate polars for reefed configurations, or at least degrade above given wind speeds.
  • Optionally, learn from your own logged tracks over time.

That last point is where onboard data logging starts to matter. If your instruments and engine data are already being recorded and time-stamped, you can rebuild empirical polars from your own sailing rather than trusting the yard's original numbers. It also lets you cross-check whether a "bad" passage was a routing failure or a sail trim problem, which is a very different conversation with the crew.

GRIB sources, resolution, and how often you refresh

All routing tools ingest GRIB files, but the models behind them are not equivalent. The main ones you will encounter:

  • GFS (NOAA, global, free, 0.25 degree, updated four times a day). The workhorse. Good enough for the open ocean, weaker near coastlines and in thermal regimes.
  • ECMWF (European, generally the best global model, often paid access at high resolution). Worth the subscription for offshore work.
  • ICON (DWD, strong over Europe).
  • Arome and Arpège (Meteo-France, high-resolution regional, excellent for French and western Mediterranean waters).

The software should let you overlay two models at the same time. When GFS and ECMWF disagree on the position of a low by 150 miles at 72 hours, that disagreement is itself useful information, and any router that only shows you one model is hiding it. For coastal work, particularly something like a Toulon to Calvi crossing where the mistral sets the tempo, a high-resolution regional model matters more than the global one.

Refresh discipline matters as much as source. A router that quietly runs on a 36-hour-old GRIB because the download failed is worse than no router at all. Look for tools that flag file age prominently and refuse to route on stale data past a threshold you set.

Connectivity, offline behaviour and power budget

Offshore routing is a bandwidth question before it is a software question. A full-resolution ECMWF GRIB over a 500-mile box for seven days is a large file over Iridium and a trivial one over 4G or Starlink. Your routing software needs to understand the pipe it is on.

Things to check specifically:

  • Can you request a bounded, low-resolution GRIB (say, 1 degree spatial, 6-hour temporal) for satellite links, and a full-resolution one when in 4G range.
  • Does the tool resume interrupted downloads or start from zero every time.
  • Does it run entirely offline once the GRIB is on board. Some newer cloud-based routers do not, which is a hard no for real offshore work.
  • What is the power draw on the tablet or laptop running it. A router that pins a CPU at 100 percent for isochrone calculations will eat your house bank faster than the fridge.

For most European cruising, a hybrid connectivity setup is now the sensible default. If you have not sorted this out yet, our note on Starlink versus 4G for onboard internet covers the tradeoffs, including how to fail over cleanly when one drops.

Integration with your instruments and the rest of your stack

A router that lives in its own silo forces you to type in your current position, boat speed and wind by hand, or at best import a GPX at the end of the passage. Modern tools should sit on your NMEA network and read live SOG, COG, TWS, TWD and sea temperature so that:

  • The current leg is compared against the predicted leg in real time.
  • Re-routes trigger automatically when observed wind diverges from forecast by more than a set threshold.
  • Your actual track is logged against the theoretical optimum, which is the only honest way to evaluate the router after the fact.

This is where onboard data infrastructure starts to matter more than the routing app itself. If your NMEA 2000 backbone is already being read and streamed off the boat, comparing plan to reality becomes something you do on a screen after landfall, not something you reconstruct from memory and a chartplotter screenshot. The wider point is that routing is one node in a broader data picture, alongside engine hours, maintenance intervals and geofencing. If you want to see how these threads connect on modern boats, our overview of AI in maritime navigation and the current app landscape for boaters both walk through what has changed in the last two seasons.

How to test a router before you trust it

Never take a new routing tool offshore for the first time on a real passage. The test protocol is straightforward and takes about a month:

  1. Backtest on a passage you have already done. Load the historic GRIB (most services keep archives), your polars, and your actual departure point. Compare the router's proposed track and ETA against what you actually did. A router that says you should have arrived four hours earlier by taking a route you know had confused sea state is not necessarily wrong, but it tells you what it optimises for.
  2. Run a week of "phantom passages" in parallel with your normal sailing. Every morning, ask the router for a 48-hour forecast route from your current position. Every evening, compare the forecast wind to what you actually saw. You are testing the GRIB source and the model as much as the software.
  3. Break the connection deliberately. Turn off the internet mid-route and see how the software behaves. Does it warn you clearly, or does it silently keep computing on old data.
  4. Try a comfort-weighted run with wave height and TWS caps set. Then remove the caps and see how much time you "gained". That number is your comfort budget in hours per passage.

By the end of that month, you will know whether the tool matches the way you actually sail, or whether it was designed for a different kind of boat and skipper.

The routing software you choose is really a proxy for a bigger question: how much of your passage planning do you want to base on data you own, versus data someone else models for you. Empirical polars, a clean GRIB pipeline, live NMEA feeds and honest post-passage debriefs all point in the same direction. The router is the visible tip of that stack. Everything underneath it is what actually decides whether the plan on the screen matches the sea outside.