The answer here is no, there is no way to do that, I'm afraid.
The format of these files is potentially compressed smile with Lucene headers and footers around them. The code we use to read these is here if you are interested. Technically you could work from it to create your own parser for the file but see below.
The difference between two snapshots is not directly in the snap-${uuid}.dat file. If you look at the documentation I linked you will find that the $snap-{uuid}.dat blob (together with the latest index-N blob) in the repository merely defines what shards can be found in a snapshot.
You can then go to the shard folders which themselves contain another snap-${uuid}.dat for each shard in the snapshot and contain a list of all the files that were added for the snapshot in each shard. The files referenced by the snap-?.dat and named as __${uuid} in the shards are the actual data files containing your documents.
The relationship between these individual files in a snapshot and the concrete documents they point at is not trivial though I'm afraid. The files are in Lucene format (documented here) and there is effectively no other way but restoring them to get their contents.
Maybe you could restore indices one by one (restoring both snapshots to different names) and then delete them again as you and compare contents that way to save resources?
There is in fact a shortcut that may help you here. Look at this API:
GET /_snapshot/my_backup/snapshot_1/_status
There is some sparse documentation for it here. But what it will return is JSON that contains the number of files added for each shard. Maybe, if you only added documents to a subset of indices you could identify those indices that have not changed as those with 0 in the file size/counts found the key incremental in all shards in the index to significantly simplify things because those with 0 changes won't need restoring? If you only added documents to a small number of indices this may be a viable path forward?