There is no feature that GitClear has iterated more times than its Diff Viewer. Since 2020, the Diff Viewer has been gradually improved every quarter, with additional functionality imbued more often than blogs are written or help pages updated. All of which is to say, if the screenshots in this help page don't match what you see when you open the Diff Viewer, it's less because this help page is out-of-date and more that the Diff Viewer is a point of pride for GitClear's developers.
As described by The New Stack and Stack Overflow, GitClear saved 29% on PR code review over 49 developer participants contrasting the code review environment in 2025. GitClear is a new type of diff viewing tool, for an era where LLMs explain changes better than commit messages do.

This page will detail how to access the GitClear diff viewer, and what bells and whistles are used to save 30% review time compared to a standard diff viewer [1].
Upon login, users are by default redirected to the Commit Activity Browser, where clicking on a recent commit will open the Diff Viewer.
If logged into GitClear, you can access the Diff Viewer for a git sha by visiting
https://gitclear.com/c/[sha]
It can be a short sha or a standard sha. For a pull request,
https://gitclear.com/p/[Provider's PR ID]
Fill up your copy buffer with a recent sha from your commit history, or a PR from Github, and you can see their most concise representation with utmost haste.
If you often review Github pull requests, the GitClear Chrome Extension provides a one-click link from Github PR to GitClear PR.
Compared to other git viewers, the GitClear PR diff viewer has a number of advantages to expedite code review.

When reviewing a pull request with various different types of changes, drag the "Review Depth" slider to control which files are default-open during review
Not all files are equally essential to review. In an age where perhaps 90% of our code is being authored by LLMs, it can feel hopeless to try to review every line. So don't.
With GitClear's configurable "Review Depth" feature, we split different types of changes by how essential they are to review. Roughly speak, we conceptualize the salience tiers as:
🔴 Essential: Database migrations, dependency changes, substantial updates to legacy files, configuration file changes
🟠 Focused: Models, large controllers, most library changes, changes to trivial files that break convention, middleware, event/exceptions
🟡 Careful: Any other settings-changing work that wasn't captured by "Essential" or "Focused", most html/view files, factories, small controllers, documentation
🟢 Complete: Everything not covered above: Tests, compiled files (that aren't ignored)
As you drag the slider further right (toward "Complete"), you'll get the full set of changes open by default. If you're strapped for time, drag it left.

Got time for reviewing 37 files, or 13?
There's nothing worse than having too little time to review a pull request, then returning later to find the diff viewer can't distinguish between what you already saw and what is new. GitClear takes multiple steps to avoid this calamity.

Each file remembers its state as of when you reviewed it
The first step is a small convenience: As you're scrolling through a code review, we'll automatically demarcate which files you have scrolled to the end of (rather than forcing you to click each file). If you want to think about the file's changes more later, you can click the button at the bottom of the file to preserve it for future review (in spite of having been already seen).
The second step is that, when a file has been marked as reviewed, it is auto-hidden by default when you revisit the PR.
The third step is that, when you've reviewed some or all of a PR when additional commits are authored, we will prepare a diff that shows only the changes new-to-you for each file. If you want to see all changes to a file including the ones you already reviewd, you can click a link to return to seeing "every change in the PR, including previously reviewed."
Want to get Claude's take on why a line changed, whether it's tested, or other applicable questions? Click the "+" next to any line to open Composer with LLM hooks:

Context-appropriate options available during PR review
Upon submitting your question, the "Deep Dive" LLM pops open to assist:

Conversing to drill into the origin for a line
If the committer's commit message doesn't answer why the code changed, this will. Feature available to Diff Digest Pro or GitClear Elite subscribers.
Now that humans are one among many authors that contributes code, GitClear offers per-line attribution for any users who install our telemetry package.

When seeking to understand the origin of a puzzling code comment, or a repeat of an existing method, the right-side bar describing the agent from whence the code sprang is usable signal.
For any reviewer wading through a pull request that can't be completed in one session, GitClear's Diff Viewer records which files were reviewed and which weren't. Armed with knowledge about which version of each file you have reviewed, we can construct a pull request diff that uses a different range of commits for various files within the pull request.

The payoff: when you return to the pull request for a second session, you'll see the changes to whichever files you reviewed previously, while seeing the entire set of changes for the files that you didn't see during the first review session.
For the incremental diffs (of what changed in a file since your first review) you can always click a link atop the file see its full difference vs the main branch.
When you only have a limited time for commit review, it's useful to get a sense for how much review work exists in each file.

Files with a full meter are files that had the greatest amount of Diff Delta accumulate within them. If you want to ensure you've seen all the substantive changes from a PR, start by clicking on the files with the full bars.
![]() | ![]() |
Most any pull request reviewer has experienced a "wtf?" moment when they encounter a large, important file being deleted in the middle of the changeset. 9 times out of 10, what really happened was that the important file or method was moved to a new location, not actually destroyed. But it often takes a minute of furtive scrolling to confirm that the faux-deleted code was actually relocated.
GitClear's diff viewer recognizes the 10-20% of changed lines that amount to a "cut and paste" operation, fundamental to refactoring a repo for reuse. Also recognized and deemphasized are language-specific keywords, find/replace statements, and lines that have already changed again, after the diff being viewed (these get an "X" as their icon, to indicate that they are no longer checked in).
If you're the developer who submitted the PR, it's useful to be able to see a consolidated list of the issues that have not yet been resolved. The box in the upper left of each PR provides it:

Each reviewer's comments are grouped below their summarizing comment. As you resolve each comment, it is removed from the list of pending comments.
Hover over any line to see the committer's explanation for why the line changed:

Want more details? Open the composer to interact with the LLM agent, as described above.
Since most GitClear users have spent a lot of time using GitHub, it's natural that they feel most oriented within the familiar iconography and color themes from the venerable home of git. For this audience, we offer a toggle built into every file for switching the diff presentation between "GitClear" and "GitHub"



In descending order from the top of the page, here are some features you'll find in the Diff Viewer.
If the work is on behalf of an issue tracker ticket (as most work on enterprise teams should be), the commit or commit group will lead with the issue tracker ticket that is being addressed by the work:

Details on the Jira ticket being implemented available after connecting Jira to GitClear
The issue tracker ticket can be automatically detected so long as the Jira's identifier is mentioned in a branch name, commit message, or pull request title/description.
Most diff viewing on GitClear takes the form of viewing grouped commits. For these cases, the next section of the Diff Viewer is a summary of what commits are being viewed:

The green bar suggests how much change was packed into each commit
You can view a commit individually by expanding it. If you're curious how the time estimates are calculated, see How GitClear estimates time used (minutes, hour, days) per commit.
After the list of commits, you can see the committer, and navigate to work that came before or after the diff being viewed:

You can also modify the time estimate, work classification, or Diff Delta by clicking the text for any of these fields.
What type of code was changed in this diff?

The color of each code category suggests the predominant type of change: green for "added," red for "deleted," blue for "updated."
Next is the line that summarizes how many files changed, with a link to update Diff Viewer settings.

If you open settings, you'll get a few options to season your diff viewing experience to taste.
To the right of the changed file list are the changed files themselves. If viewed from the Commit Activity Browser, files are collapsed by default and summarized with AI:

Clicking on a file will open it to show the changes contained therein. Clicking the "x" will allow you to configure ignoring files like the one clicked (you can pick whether to ignore the specific file, or its directory). The green bar on the right indicates how much Diff Delta (change energy) was accrued in each file. The color of the icon at the left edge hints at the main type of change that happened: green=add, red=delete, blue=update, purple=find/replace, gray=no-op.
When a file is opened, you're on to the diff itself.
The default Diff Viewer settings on GitClear will dynamically pick whether to show diff files in "Unified" or "Split" view. If there were numerous additions and deletions within a file, Split view is used, otherwise, Unified view is employed to show the changes:

By default, in Unified view, the "before" side of changes is visible upon hovering the operation icon. Hovering on the operation icon also reveals other details about the change:
How much Diff Delta did the change register?
Was there a "before" side of this line that is auto-hidden?
What was the commit message in which the last meaningful change to this line occurred?
Link to view commit as standalone
If you click the "+" icon, you'll be taken to GitClear's code comment editor.
If you click on the "+" icon, you can leave a comment.

It has all the standard formatting options like bold, italic, highlight, and headings. It also allows selecting Slack-style emojis, and a triple-backtick will open a code editor that will format the code according to the type of file the comment is left within. It will remember indentation levels, if you want to suggest a method or if statement.