This is not correct. Each Elasticsearch snapshot is a full snapshot.
Each shard in Elasticsearch is a Lucene index, and this is built based on immutable segments that are merged into new immutable segments as data is added, deleted or modified. The incremental aspect of snapshots is that segments that have already been snapshotted and still exists are reused in subsequent snapshots and not copied into the repository repeatedly. The repository keeps track of which segments are in use by which snapshots and only delete the segment once it is no longer in use by any snapshot.
Once indices no longer receive data or updates and effectively become read only, the segments will no longer change and not add to the repository when new snapshots are taken. If you however have indices that are continously changing new segments will continously be created and the repository will likely have the same data in multiple different segments and therefore take up more space.
This blog post is very, very old, but I believe it still explains the basic principles (still largely valid) quite well.
The best way to handle snapshots therefore depend on your use case. Can you share some details about your use case and what your requirements around snapshots are?