I'm particularly interested in diff-based visualizations. Code diffs are the most straightforward and easy as they're used for a long time and have a lot of examples of 1, 2, and 3 pane views. For example, this two-pane view showing an addition: Code Diff

Another type of diff visualization is graph diff’ing, often used in graph views of assembly code. Here’s an example: Graph Diff

And finally, the least sophisticated is binary diff’ing (diff’ing arbitrary binary files to see changes in individual bytes). This is the area that gets the least love. Here are a couple of typical examples:

Binary Diff 1 Binary Diff 2

Both of these are pretty bad. I want to expand them, and make a somewhat usable diff of large binary files that are a couple gigabytes in size. To put this in perspective, I can fit about 1696 bytes on a screen. We're talking 633,102 screenfuls of data at a legible font size. So, just shrinking font-size isn’t practical.

I’m wondering what ideas people have for visualizing binary diffs in an easily navigable way. I figure it’s got to have some sort of zoom capability that may zoom into a standard binary diff that people are used to. I'd like to see other peoples' thoughts.

  • What is the nature of the diffs you expect to find? Are they blocks of insertions and deletions, or chunks that have been wholesale rewritten, or runs of minor increments of shifting, or patterns of reversals, or something else again?
    – Erics
    Jan 21, 2012 at 1:50

2 Answers 2


I would imagine a UI similar to this


Where you can see the whole file at a large level and then you can scroll into particular sections that are signified as different. I would think of this more like google maps however in process but in content to that link.

Also in that link you see a grid of size comparison to where you are, this could be a colour coded area to see you are zooming into different areas, and the other different areas are over there in relation.

It sounds like a very difficult thing to imaging because of the sheer scale and lack of consistency that comes with binary.

  • Interesting concept but I admit I can't imagine it applied to a practical UI in this case.
    – Ben Brocka
    Jan 20, 2012 at 21:10

Comparing arbitary binary files is a hard problem - this difficulty is caused mostly because the differencing algorithm has very little information on the semantics of the bytes.

In comparison (no pun intended), comparing source code files is much easier as the semantics of the files are much more complex - unicode (or ascii) code points arranged into a sequence of lines.

Similarly, I'm sure your binary files do contain some kind of structure - leveraging that structure will make it much easier both to find meaningful differences and to visualise those differences.

As an analog to your problem, imagine trying to do a binary comparison of ZIP files without teaching the tool about the structure of the file. It's very hard to come up with anything meaningful. But, if the tool understands the structure of ZIP files, large chunks of the problem become much simpler, as you can leverage that knowledge of the structure to operate at a higher level of abstraction.

Examples include:

  • When member files have simply been stored in a different order
  • Simple file renames
  • Files that are identical but compressed with different settings

With some information on the semantics of your binary files, I'm sure we'll (collectively) be able to suggest some good visualisations.

  • I think this is the best answer. I hope to produce something concrete I can get critiqued along these lines.
    – Tom Ritter
    Jan 24, 2012 at 1:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.