More often, you'll hear key sizes discussed in bits rather than bytes. So, 32 bytes = 256 bits. 16 = 128, 24 = 192.
In theory, yes, longer key lengths are more secure, as there are more permutations of the key possible. Each additional bit means twice as many possible keys, so doubles the amount of time necessary to brute force the key. That being said, physics suggests it's impossible to even brute force 128 bits. So, in reality, situations where 256-bit crypto is being used for one of two reasons: 1) they want additional safety margin if weaknesses (but not a full break) are found in AES, or 2) they want to be able to market it as "256 bit crypto!" In other words, it's often used for the warm-and-fuzzy feeling of "better" crypto.
Way more important than the key length you choose is how you create your key. If your keys are created by a human at a keyboard choosing a password, they're highly unlikely to come up with 128 bits. According to NIST, based on studies of common password practices, a human chosen password would need to be 112 characters long to give 128 bits of entropy. Given that users are unlikely to type 112 characters, your key generation strategy may be the weak point (again, assuming user-generated keys). Consider using something like PBKDF2 to harden user input into keys.
If you're generating the keys, make sure you use a quality source of entropy, like
openssl_random_pseudo_bytes in PHP. Do not use
mt_rand, as those are not cryptographically secure, and are predictable to an attacker.