Sodium crypto_aead_aes256gcm_encrypt ciphertext length > plaintext length Using the crypto_aead_aes256gcm functions from Sodium produces a ciphertext of "at most mlen (plaintext length) + crypto_aead_aes256gcm_ABYTES bytes (16 bytes) are put into c (ciphertext), and the actual number of bytes is stored into clen if clen is not a NULL pointer. The phrase "at most" is deceiving because, in testing, ciphertext length is always plaintext length + 16 bytes. Why is this the case if in the specifications for GCM the output is a ciphertext, denoted C, whose bit length is the same as that of the plaintext (5.2.1.2). 

I was going to attempt to read/write files using this, so would I just read 32 bytes at a time?
The result you are getting is the cipher text (the encrypted data) plus 16 bytes of authentication data. The authentication data (mentioned directly below the ciphertext in the resource you cited) ensures that the ciphertext cannot be changed without the change being detected, and is the (most important) thing that distinguishes GCM from regular CTR-Mode.

The authentication data is the same length, no matter how much data you encrypt. So, if you encrypt 1024 bytes, you will still only get 16 bytes of authentication data. This means that you will only have to plan for those extra 16 bytes once and can read / write all remaining data as usual, although it would probably be a good idea to check some open source projects using the same library and cryptography and see how they are doing it, just to be sure you're not making any mistakes (at least that's what I usually do).

Edit: Also note that implementation questions are better suited for Stackoverflow, as the Crypto Stackexchange mostly deals with the concepts and not the implementations of cryptography.