First I will start with AES-CTR. This is a mode which turns a block cipher into a stream cipher. Since AES has a 128-bit block size, the output of the primitive is in blocks of 16 bytes. If you have a 3 byte message, 3 bytes is kept from that block to encrypt the plaintext via XOR. A broken implementation may not truncate. CTR requires a Nonce, which is generally included with the ciphertext and is usually 96-bits (12 bytes) in length, making that final message length 15 bytes. Salsa and ChaCha also require a Nonce.
Other variants of CTR mode include the authenticated GCM, which would then add an authentication tag to the ciphertext, at an implementation defined length.
Nonces and authentication tags are generally a multiple of 8 bits, so if you are encrypting a byte string, you should end up with one. Other data required to decrypt the message may be concatenated to the ciphertext, such as KDF iteration counts and salts, cipher or KDF identifiers, and message sequence identifiers. If an authenticated mode is used, and these are processed as additionally authenticated data, they are required to decrypt as per specification, even though without them you may still be able to recover the plaintext. Additionally authenticated data may included something that is not part of the ciphertext, such as the email or IP address of the sender.
Some stream ciphers do not explicitly require a Nonce, but they may be processed as part of the key, and still need to be included with the ciphertext.
Various implementations may obfuscate or operate on the plaintext prior to encryption. Plaintext compression can substantially change the ciphertext size, or may have no effect at all, depending on the content. Obfuscation may pad the entire message to 140 bytes, so it can then be plaintext encoded to fill an entire SMS message, hiding the true message size.