Answer: Give each task a start day, a length in days, a phase and a percent done, and the chart draws one bar per task on a calendar with weekends shaded. The sample website relaunch runs 42 days end to end, even though its seven tasks add up to 83 task-days.
Enter tasks, get a real timeline with phases, progress, and weekend shading
| Type | Name | Meaning | Example |
|---|---|---|---|
| FS | Finish-to-Start | B starts when A finishes | Design finishes, then build starts |
| SS | Start-to-Start | B starts when A starts | Testing begins as coding begins |
| FF | Finish-to-Finish | B finishes when A finishes | Docs end when the build ends |
| SF | Start-to-Finish | B finishes when A starts (rare) | Old system retires as new one goes live |
Finish-to-Start covers roughly 90% of real project links. If you can only state one relationship per task pair, state that one.
| Phase | Share of Calendar | What Runs Concurrent |
|---|---|---|
| Discovery & planning | 10–15% | Stakeholder interviews, requirements |
| Design | 15–20% | Wireframes → prototypes → review |
| Build | 35–45% | Frontend, backend, content prep |
| Test & fix | 15–20% | QA cycles overlap late build |
| Launch & stabilize | 5–10% | Deploy, monitor, hotfixes |
Each task carries four numbers and a phase: when it starts (day offset from the project start), how long it runs, how complete it is, and which phase it belongs to for color. The chart lays one row per task on a calendar grid, shades weekends, marks the project start date on the axis, and draws a progress overlay inside each bar. Everything renders as SVG, so the download is a clean vector you can drop into a slide deck or spec.
Start with your milestone list, then break each milestone into tasks of one to five days; longer bars hide slippage. Enter tasks top to bottom in kickoff order, using the start-day column to shift things later or run them in parallel. Phases exist for color and legend, so use them consistently. When a client asks what a one-week delay does, move the affected bars and watch the finish date move with them.
The sample project is a realistic website relaunch: discovery on days 0–4, design 3–12 overlapping discovery's tail, build 10–32, content 14–30 in parallel with build, QA 28–38, and launch 38–41. Total: 42 calendar days. Notice the overlaps: content migration runs entirely inside the frontend build window, and design starts before discovery wraps up. Add the seven durations together and you get 83 days. The chart shows the real finish is day 42, because so much runs in parallel. Spotting that overlap, and seeing which tasks don't overlap, is the whole value of the chart.
Here's the sample project from the Load sample project button, laid out as numbers. Day 0 is whatever start date you pick. A task that starts on day 10 and runs 18 days occupies days 10 through 27 and is done by the start of day 28.
| Task | Phase | Start day | Days | Done by day | % done |
|---|---|---|---|---|---|
| Discovery & requirements | Planning | 0 | 5 | 5 | 100% |
| Wireframes & design | Design | 3 | 10 | 13 | 100% |
| Backend build | Build | 10 | 18 | 28 | 80% |
| Frontend build | Build | 12 | 20 | 32 | 70% |
| Content migration | Content | 14 | 16 | 30 | 40% |
| QA & bug fixes | Test | 28 | 10 | 38 | 10% |
| Launch & stabilize | Launch | 38 | 4 | 42 | 0% |
The finish date is simply the largest "done by" number, 42 here. QA starts on day 28, the day the backend wraps, but frontend work is still running until day 32. That's a deliberate overlap in the sample. In a real plan you'd want to ask whether QA can really start before the frontend is finished, or whether that's a wish.
The chart pads the grid to whole weeks so the week lines stay even. It takes the last finish day, adds two days of breathing room, and rounds up to the next multiple of 7. For the sample that's 42 + 2 = 44, rounded up to 49. The caption under the chart reports the grid width, not the project length. Your project ends where the last bar ends.
Calendar days. Weekends are shaded grey so you can see them, but bars run straight through them. A task you enter as 10 days covers 10 squares on the grid, Saturday and Sunday included. If your estimates are in working days, convert them before you type them in, or every task will look shorter than it is.
| Working days of effort | Calendar days if it starts Monday | Calendar days if it starts Wednesday |
|---|---|---|
| 1 | 1 | 1 |
| 3 | 3 | 3 |
| 5 | 5 | 7 |
| 10 | 12 | 14 |
| 15 | 19 | 21 |
| 20 | 26 | 28 |
| 30 | 40 | 42 |
Counts assume a Monday-to-Friday week with no public holidays. A one-week task that starts midweek crosses a weekend, which is why the Wednesday column runs two days longer. For exact counts between two real dates, including holidays you want to skip, the Date Difference Calculator gives business days directly.
Your task list saves to this browser's local storage after every edit, so it's still there when you come back. The project name, start date and zoom setting aren't saved. The start date resets to today each time you open the page. Because every task is stored as an offset from day 0 rather than a fixed date, the whole chart slides forward to the new start date. That's handy for "if we kicked off today" planning, and confusing if you expected the dates you set last week. Set the start date again before you download or share.
Two smaller things to know. Task names longer than 24 characters are cut off in the chart's label column, so keep names short or put the detail elsewhere. And the zoom only changes how wide each day is drawn. At the default 22 pixels per day, the sample downloads as a 1,248-pixel-wide SVG; at 10 pixels it's 660 pixels, which fits a slide more comfortably.
There's no diamond marker, so use a one-day task. Give it a clear name like "Client sign-off" and put it in the Launch phase so it shows up red. If you're tracking day-to-day progress rather than a schedule, a Kanban Board is a better fit: it shows what's moving right now, where a Gantt chart shows when things should happen. Our guide on how to make a Gantt chart covers breaking a project into tasks in more depth.
Scheduling anything where tasks run over time: seeing what happens when, which tasks overlap, where the critical path sits, and what a delay in one task pushes back downstream. It answers the question a task list can't: given all this work, when does the project actually finish?
Estimate in the units you actually track (days for most projects), then add buffer to the tasks with external dependencies, since those slip most. A practical default from project management practice: take your honest estimate, and if the task involves anyone outside your team, add 50 percent.
The longest chain of dependent tasks from start to finish. If any task on that chain slips a day, the whole project slips a day, while tasks off the chain have slack. Most Gantt tools highlight it; on paper you find it by tracing dependency arrows and looking for the chain with zero room.
Yes. The Download SVG button gives you a vector file that scales cleanly into slides, docs, or design tools, and your browser's print dialog can print the page directly. The chart also re-renders on every edit, so what you see is always current.
It draws the timeline view: bars, phases, progress, and calendar context. It doesn't draw dependency arrows, which keeps it fast and simple. If you need dependency logic and leveling, you need a full project management tool; if you need a clear chart to share, this is it.
No. Weekends are shaded so you can see them, but a task's Days value counts calendar days, so a 10-day task covers two weekends' worth of squares if it spans them. If you estimate in working days, convert first: 10 working days starting on a Monday is 12 calendar days.
Tasks are saved as day offsets from the start date, and the start date itself isn't saved. It resets to today each time the page loads, so the whole chart shifts forward. Your tasks, durations and progress are unchanged. Set the start date back to your real kickoff before downloading.