The way OverlayFS works is that there's a base directory. And then there's an overlay directory that only contains the changes. Docker is based on OverlayFS.

There's two main ways overlays are used, first at build time, each line/command generates a new overlay based on the previous base, so when you do something like

FROM debian RUN apt-get update

it creates a base from the debian image , and then creates an overlay that only contains the changes introduced by apt-get update.

If you use docker inspect or docker show on the image you get a json showing exactly where the overlay directories are, you just need to navigate the overlay directory.

Second: on runtime. [Assuming you are not using volumes, (and if you use volumes, just make sure the volume starts out as empty, instead of sharing your host files)] OverlayFS is used for the runtime file changes as well, the last image is used as a base, and every files changed during runtime are added to the runtime overlay. That filesystem won't be deleted, if you only stop the docker container, the runtime files will still be present, and you can reach them by docker inspecting the running docker processes/instances, and then navigating the overlay fs as you would any directory.

You can also just use overlayfs, as far as I recall, you just use mount and unmount while specifying the OverlayFS driver and special parameters like base and overlay. Conjugating a chain of overlays is a bit more complex, but it's the same interface.