One line per stop
Each line is day | time | what | note, and only the first three matter. The day can be written as Day 1, 1, or — if you filled in a departure date — as a real date like 09/01/2026, which gets converted to a day number by counting from departure. Only digits are read out of the day field, so "first day" has nothing to read and is rejected. Tabs work in place of pipes, so two or four columns pasted out of a spreadsheet come straight in.
Times take either format: 9:00 AM or 09:00. A time with no AM or PM is read on a 24-hour clock, so 14:00 is the afternoon. Line order does not matter at all — each day is sorted by time before the table is built, and the tool reports how many days it had to reorder so you know it did something.
Reading the "until next" column
That column is the interval from the start of one stop to the start of the next. It therefore contains two different things at once: how long you spend at the first stop, and how long it takes to get to the second. This is the single most misread number on any itinerary. Three hours between the museum at 9 and lunch at 12 is not three hours of slack if the museum takes two.
The tightness and looseness thresholds should be set to the trip, not left at the defaults. A city trip on foot might call 20 minutes tight and 4 hours loose. A trip with two-hour drives between stops wants a much higher loose threshold or every interval gets flagged. If you want a stop's actual duration modelled, add a second line for leaving it — Day 2 | 11:00 AM | Leave the museum — and the interval after that line becomes real travel and slack.
Time zones, plainly
There is no time zone handling in this tool. Nothing is converted, no offsets are applied, and daylight-saving changes are invisible to it. Every time is stored and printed as the exact characters you typed.
For a trip that crosses zones, the way to use it is to write every stop in the local time of the place where it happens, which is how the boarding pass and the hotel confirmation are written anyway. The consequence is that intervals spanning a zone change are differences between two clock readings rather than elapsed time: a flight leaving at 9:40 AM in one zone and landing at 12:20 PM in another shows as 2h 40m regardless of how long you were in the air. Read those particular intervals as "what the clocks said", and do not use them to plan a connection. A day containing a clock change is best entered as the day's local times and understood as one hour shorter or longer than it looks.
The printed sheet and the text version
Two outputs come out the other end. The printed itinerary has a checkbox column and a day heading per page section, and paper keeps working when a phone is dead, when there is no signal in a canyon, and when four people need the same information at once. The text version is shaped for pasting into a group chat.
The blank template is for the stage before any of this, when the dates exist and nothing else does: ask for the number of days and you get pre-formatted lines with placeholder times, which you paste back into the stops box and fill in. It saves fighting the format while you are still deciding where to go. None of this is stored — the page forgets everything on refresh, so the copy you print or paste is the copy you keep.
Questions people ask
How do I show how long something takes?
Add a second line for leaving it. "Day 2 | 9:00 AM | Museum" followed by "Day 2 | 11:00 AM | Leave museum" puts the two hours in the table explicitly, and the interval after the second line is then genuine travel and slack rather than a mixture. If the extra lines make the sheet too long, put "about 2h" in the note column instead and read the intervals with that in mind.
What about something that runs past midnight?
Split it across two days. A show starting at 11 PM on day 1 and ending at 1 AM is entered as a stop at 11 PM on day 1 and another at 1 AM on day 2. Each day is modelled as 00:00 to 23:59 only, and no interval is computed across a day boundary, so the last stop of a day always shows as the last of the day rather than reaching forward into the next one.
Does it check opening hours or flight times?
No. It has no data about anything — no venues, no closing days, no schedules, no holidays. It sorts and subtracts what you type and nothing else. Every time on the sheet is your responsibility to confirm with the airline, the railway and the venue, and the printed footer says so because that is the failure mode of a good-looking itinerary: it looks authoritative while quietly repeating a time somebody wrote down wrong two months ago.
Is anything sent anywhere?
No. All of it runs in your browser: the parsing, the sorting, the arithmetic and the print document. Nothing is transmitted, nothing is stored, and closing the tab discards it. That also means there is no version to come back to, so print the sheet or copy the text before you close the page.