Checking the result of a Gantt chart is not a separate tool, a separate upload, or a separate report: the SVG string that powers the on-screen preview is the same string that builds the downloaded file, so whatever you see in the browser is exactly what you save. In Gantt Chart Maker that preview-to-download relationship is deliberate, and it shapes how a result is reviewed. Once generation succeeds, the chart on the page is the chart that ships, which means every visual choice — bar position, bar width, tick density, label content, axis range — is something you can verify before exporting instead of after.
The verification step matters because Gantt charts are easy to misread. A bar that starts a day too early, an axis that compresses a long year into a handful of labels, or a label that was supposed to read as a date but rendered as a number can quietly travel into a slide deck, a printout, or a hand-off document. Running through a short check before you download turns those silent errors into visible ones and keeps the exported file honest. This guide walks through what to look at, in what order, and why the on-screen preview is the source of truth for the file you save.
What "checking the result" actually means here
For a Gantt chart, "checking the result" usually refers to one of two things: a sanity check that the bars, dates, and labels reflect the schedule you typed, and a fit check that the chart communicates the timeline well enough to share. A Gantt chart built from strict YYYY-MM-DD task rows with inclusive dates, safe SVG labels, and day or month ticks collapses both of those into a single visible artifact. There is no hidden report, no companion table, and no side panel; the rendered SVG is the entire output.
That design has two practical consequences. First, every value you want to confirm is on the canvas: the title at the top, the task labels down the left side, the bar start and end positions across the calendar axis, and the tick labels along the top. Second, because the chart is produced from validated input rather than interpreted input, a successful render is itself a check — every row was syntactically valid, every date was a real proleptic Gregorian UTC calendar date, and every end date was on or after its start date. The check is the chart, and the chart is the file.
Review the rendered chart in seven concrete steps
Open the tool and work through these steps in order. The goal is to confirm that the bars, ticks, and labels match the schedule you intended before you save anything.
- Add an optional title and paste between 2 and 30 non-empty task,start,end rows. Every non-empty row must contain exactly two literal commas, leaving three fields: a task label, a start date, and an end date.
- Confirm each date is in exact YYYY-MM-DD form and uses a real UTC calendar value. Four digits, a hyphen, two month digits, a hyphen, and two day digits — no slashes, no time text, no timezone suffix.
- Click Generate. If any row is malformed, the whole request is rejected and no partial chart appears; if a preview renders, every accepted row was accepted.
- Read the title at the top of the preview, then read the task labels down the left edge to confirm they match your input in order, including any duplicates.
- Walk the bars left to right. Each bar's left edge should land on its start date, and its right edge should land on its inclusive end date. A January 1 to January 3 task occupies three day cells, and a same-day task occupies one.
- Read the tick labels along the top axis. Schedules of 62 days or fewer use deterministic day ticks; longer schedules switch to month ticks. Day tick intervals expand to keep roughly nine labels while always including the first date and the last date.
- When the bars, ticks, and labels all line up, click the download action to save the standalone SVG built from the same string you just reviewed.
Why the preview and the downloaded SVG match
The preview is not a watered-down version of the chart, and the download is not a re-rendered copy. Both are produced from one and the same SVG string in the same browser tab. Gantt Chart Maker composes the SVG once, shows it on the page, and — when you click download — wraps that exact string in a Blob and triggers a same-origin anchor download. The Blob URL is revoked as soon as the title or the data changes, a result is replaced, generation fails, or the component unmounts, so you never end up with a stale preview sitting next to a fresher file.
This matters for verification because it removes a whole class of doubt. You do not need to re-open the downloaded file in a separate viewer to confirm the bars are the same ones you reviewed, and you do not need to compare the saved file against the preview pixel by pixel. The on-screen chart is the file, defined by the W3C SVG 2 vocabulary, with a fixed 1,100-pixel logical width, a row-dependent height, a white background, grid lines, label text, and accessible role and label attributes. If you can read it, you can save it; if you cannot, no download button needs to be pressed yet.
Reading bars, ticks, and labels before you save
A few quick visual checks catch most Gantt chart errors before they leave the page. Use this comparison to decide whether the axis is telling you what you expect:
| Schedule length | Tick mode | Tick label format | Why this mode is used |
|---|---|---|---|
| 62 days or fewer | Day ticks | YYYY-MM-DD | Day tick intervals expand to keep roughly nine labels while always including the first date and the last date. |
| 63 days or more | Month ticks with a fixed step | YYYY-MM | Thousands of day labels would crowd the axis; the fixed month step is calculated from the full month count instead. |
Once the axis is in the right mode, the bars themselves deserve a second look. Bar positions are whole UTC-day offsets from the earliest start, and widths are each task's inclusive day count, so a bar that looks one cell short usually means an off-by-one end date in the source row. To verify an inclusive span by hand, use the simple formula inclusive days = end day number − start day number + 1. For example, a row of Wireframe,2025-01-01,2025-01-03 has inclusive days = 3 − 1 + 1 = 3 day cells, and a row of Launch,2025-03-15,2025-03-15 has inclusive days = 0 + 1 = 1 day cell. If a bar in the preview does not match that count, the input is the place to correct it, not the chart.
Label text is the last thing to confirm. Task labels, the optional title, and the tooltip text are all escaped to safe SVG text, not parsed as markup, so an ampersand, angle bracket, quote, or apostrophe in your source row will appear as the character you typed rather than as a stray element. The chart describes calendar occupancy only — it does not show hours, business days, work effort, percentage complete, or resource capacity — so a result that looks "wrong" in any of those directions is actually the tool telling you it is the wrong tool for that question.
Download the verified chart as a standalone SVG
Once the preview passes your review, the download step is the simplest part of the workflow. The file is a single, self-contained SVG with no external fonts, no remote images, and no script tags; the W3C namespace, the viewBox, the role, and the accessible label are all written into the same string you reviewed. Parsing, UTC date math, SVG construction, preview rendering, and the Blob download all happen inside the current browser tab, so the schedule never leaves the device.
If a future run produces a chart that is too large to serialize within the 100,000-code-unit output budget, the request fails and no partial file is produced — that ceiling is checked against the complete serialized string, not sampled, so there is no risk of a silently truncated download. The same boundary rule applies to the inputs: raw schedule input is capped at 20,000 code units, labels at 80, and the optional title at 100, each checked as a single limit. A chart that opens cleanly on the page, on the other hand, has already cleared every one of those checks, and the file you save is a faithful copy of the chart you just verified. For related reading on catching errors before they reach the download, see avoid mistakes when you make a Gantt chart.