GitHub mark file as viewed: the checkbox that keeps your place, and where it fails
Othman Shareef · October 4, 2026 · 6 min read
Buried in the corner of every file header on the Files changed tab is the most underrated control in GitHub’s review UI. The GitHub mark file as viewed checkbox does one small thing: it remembers which files you have already read. In a five-file PR that is pointless. In a fifty-file PR it is the difference between a systematic pass and rereading the same test fixture four times. This piece covers the verified behavior, the workflow that gets the most from it, and the gaps that eventually send you looking for more.
What the GitHub mark file as viewed checkbox does
The behavior, verified against GitHub’s docs on reviewing proposed changes: after you finish reviewing a file, you can mark it as viewed and the file collapses. The progress bar in the pull request header shows how many files you have viewed. And the detail that makes the feature trustworthy: “If the file changes after you view the file, it will be unmarked as viewed.” That last rule matters. A place-keeper that lied about staleness would be worse than none, because you would skip files that changed under you. GitHub chose correctness over comfort here, and it is the right call.
Why place-keeping matters in large PRs
Reviewing a large diff is fundamentally a working-memory problem: you are building a mental model faster than the file list can erode it. Every time you lose your place, you pay a re-orientation tax, scrolling to figure out what you have covered. PRs are hard to review in large part because the diff view gives you no narrative structure, and on a big change the viewed checkbox is the one piece of state that survives a coffee break. Used with discipline, it turns an amorphous wall of files into a shrinking queue, which is also the core move in our guide to reviewing large pull requests: make progress visible, or fatigue will make the decisions for you. There is a secondary benefit that goes underappreciated: the progress bar is a cheap honesty check. If you approved a forty-file PR and the bar says nine files viewed, you know exactly what kind of review that was, and so do you the next time you are tempted to repeat it.
Pair it with the file filter
Viewed state gets sharper when combined with the file filter dropdown, documented in filtering files in a pull request. You can filter the diff by file extension, by lack of an extension, by code ownership, or by dotfiles, and you can temporarily hide deleted files or files you have already viewed. The combination is the workflow: filter to one slice of the change, read it, mark as you go, hide viewed files, and watch the remaining set shrink to zero. On a mixed PR, filtering to .sql first, then source, then tests imposes at least a crude reading order on a list that is otherwise alphabetical. The file tree helps here too, with one documented quirk: it does not display if your screen is too narrow or if the PR contains only a single file, so on a laptop with a split screen you may be navigating by filter alone.
The gaps
- No folder-level marking. Two hundred files of generated code under one directory means two hundred clicks. Filters can hide slices, but nothing marks a subtree as dealt with.
- Resets are all or nothing per file. The auto-unmark is correct, but a rebase that touches every file wipes your progress wholesale, and nothing tells you what changed inside each unmarked file. That pain is the subject of our piece on re-reviewing with interdiffs: what you want after a push is the delta since your last read, not a fresh start.
- No memory of conclusions. Viewed records that you looked, not what you thought. Come back Monday and the checkbox cannot tell you which files worried you.
A workflow that gets the most out of it
Within GitHub, the discipline that works: first sweep the trivial tail (lockfiles, snapshots, generated output) and mark it viewed immediately, so the progress bar reflects real work. Then filter by slice, read in dependency order as best you can, and leave unviewed anything you intend to revisit, treating the unviewed set as your literal queue. Comment as you read so conclusions live somewhere. Disclosure: the ceiling you eventually hit here, wanting reading order, grouping, and place-keeping that survives a force-push, is what we built Pyor for; it organizes the diff and scopes it per commit so your place is structural, not a row of checkboxes. But even with no new tools, viewed state used deliberately beats the default of scrolling and hoping.
