Your timestamps can be clickable in the description while the progress bar still shows no chapter divisions. That feels like one problem, but it can come from different surfaces: the chapter entries, your channel’s access, the video’s publication state, or the app and device being used to watch it. Identify the failing surface first, and you can stop repeatedly rewriting a description that may not be the real issue.
Missing YouTube chapters can point to two different problems
When people say “timestamps aren’t working,” they may be describing either description navigation or timeline chapters. Those are related, but they are not the same visible result.
- Description timestamp navigation
- A viewer selects a timestamp-and-title entry in the video description and playback moves to that point.
- Timeline chapter navigation
- The player divides the progress bar into sections and displays chapter titles as the viewer moves through the video.
YouTube documents manual chapters as timestamp-and-title entries in a video description, while its viewer guidance describes chapters as sections in the progress bar. The platform therefore treats these as separate ways to navigate a video; one working does not, by itself, prove that the other should be visible. YouTube’s explanation of chapter navigation describes both surfaces.
Example: the links work, but chapter markers do not
Imagine a 42-minute tutorial with these entries in its description:
00:00 Introduction00:12 Materials and setup08:30 The main demonstration18:45 Troubleshooting the result
If selecting those entries moves playback correctly but the progress bar remains visually unsegmented, you have already learned something useful: at least one kind of timestamp navigation is present. The next check should not be “rewrite every title.” Instead, verify the documented chapter requirements, account access, and the published playback surface in that order.
This example is only a symptom pattern, not proof of a particular cause. A list that looks reasonable to a person is not a guarantee that YouTube will render visible chapters.
Check the creator-side requirements and account state
Start with the video and channel, not the phone on which you happened to notice the problem. YouTube’s manual-chapter rules provide the firmest checks available, but they are requirements rather than a promise that a compliant-looking list will always render.
- Check the opening timestamp. The first manual chapter must begin at
00:00. If your list starts later, correct that documented requirement before drawing conclusions from the player. - Count and order the entries. A manual chapter list needs at least three timestamps arranged in ascending order. Keep this check limited to the documented rule; the available guidance does not establish how every unusual formatting variation is parsed.
- Inspect the spacing between chapters. Each chapter must be at least 10 seconds long. Pay particular attention to neighboring timestamps that are close together. The available evidence does not establish every boundary-case behavior, so do not treat one edge case as a complete explanation of the system.
- Check Feature eligibility. Adding chapters is listed as an Advanced feature. In YouTube Studio, open Settings, then Channel, then Feature eligibility; check Feature eligibility in YouTube Studio to see the access information for your channel.
- Look for documented channel limitations. YouTube says chapter access may be unavailable for channels with active strikes or for content that may be inappropriate to some viewers. These are documented limitations, not a complete list of every possible reason a feature might be unavailable. YouTube’s Video Chapters requirements covers the relevant rules and restrictions.
- Confirm which chapter system you expect. Manually entered chapters take precedence over automatically generated chapters. That is a precedence rule, not evidence that the two systems are fighting each other. If you have supplied manual entries, judge the result against those entries rather than assuming automatic chapters will fill in a different version.
- Test the published video. YouTube distinguishes uploading, processing, and publishing states. Make sure you are testing the public video, rather than relying only on an editor view or a video that has not reached its published state. The available upload documentation does not provide a chapter-specific processing-time guarantee, so there is no supported 24-hour rule—or any other fixed waiting period—to use as a diagnosis.
After these checks, record the exact symptom. For example: “All description entries are clickable, but no progress-bar chapters appear on the published watch page.” That description is much more useful than “chapters broken,” especially if you later need support.
Verify the published video on the surface where it fails
The editor is not the final viewing environment. Open the published video and check the two outcomes separately: first select a description timestamp, then inspect whether the progress bar is divided into chapter sections and whether chapter titles appear in the player.
As a practical verification step, compare the result on a desktop browser and a phone when both are available. An independent troubleshooting guide recommends checking the published video across desktop and mobile rather than relying only on the editor view. This cross-surface test can tell you whether the symptom follows the video or appears only in one playback environment; it is not an official requirement and is not a confirmed fix.
Record the environment alongside the result: published or preview view, desktop or phone, and whether the failure affects selecting timestamps, seeing chapter divisions, or both. Keeping those symptoms separate prevents a navigation problem from being mistaken for missing chapter metadata.
Handle mobile-only chapter failures as a separate possibility
Recent community discussions include reports of chapters failing across multiple videos on a phone while working on a laptop. Other users described timestamp or chapter selections improving temporarily after a reload or after reopening a video from viewing history. Those accounts support a useful testing branch—compare devices and playback surfaces—but they do not establish why the behavior occurred, and they do not make restarting, reloading, clearing cache, or reopening from history reliable fixes.
An independent issue report also describes chapter selection failing to move playback in a specified Android app environment and version. Keep that observation in its proper scope: it is environment-specific reporting, not evidence that all Android users or all current official YouTube builds have the same problem.
If description links and timeline chapters both work on a laptop but chapter selection fails on one phone, the available evidence points you toward documenting a playback-environment symptom rather than deleting and rebuilding the chapter list immediately. That is a practical interpretation of the test result, not a confirmed diagnosis.
Once the documented chapter requirements, Feature eligibility, channel limitations, manual-chapter precedence, and published state are checked, stop changing the description at random. Isolate the playback environment, note exactly which interaction fails, and escalate with those details if the problem remains.
Document the result before using YouTube support
For a persistent problem, capture the chapter entries, the video’s published status, the surface where the failure occurs, and whether description navigation behaves differently from timeline navigation. A screenshot or short recording can make that distinction clear.
Then use YouTube’s feedback flow. YouTube’s mobile feedback procedure can include screenshots and logs and directs users toward the Known Issues page and Help Forum. That gives you an official route for reporting a reproducible symptom, but it does not promise a diagnosis, response, or repair timeline.
The most valuable outcome of this process is not a new timestamp list. It is a precise answer to “which surface fails?” If the metadata or account state is responsible, you have a focused creator-side correction to make. If only one app or device fails, you have a documented playback issue rather than a reason to keep rebuilding otherwise verified chapter entries.
