I've been delving into cryptography for fun and trying to implement a visualization for AES using image encryption. So far, represented each pixel's RGB values as hexadecimal numbers, then split it into an array of 16 character strings. I know that AES is a block cipher, so I have to split them into 16 character strings, but how am I supposed to handle when the string becomes less than 16 characters? I've heard that I should just pad it and add more characters to fit it into 16 characters, but I'm not sure if that's correct, since the padded characters won't be represented in the final image, and be able to be decrypted.
CAUTIONARY NOTE: Beware that the vast majority of countless articles that discuss "image encryption" using computers (rather than using essentially optical means) are junk science. I don't know any article with "image encryption" and "AES" in the title (as the question does) that's worth studying (I welcome a link in comment if I missed one).
Encrypting digitized images (rather than other kinds of digital data) using AES requires no special crypto or preprocessing. As for other kinds of digital data, compression (if used) must be applied before encryption, and decompression after decryption; and then one should examine the consequences of the fact that crypto does not hide the length of what's encrypted.
There's no good reason that the plaintext (what's encrypted) go thru hexadecimal (a system of representation where 4 bits are encoded into a character): this would typically double the size compared to using the raw bytes. Hexadecimal is a way for eyes to see raw bytes, or express the ciphertext (result of encryption) as text (even though there are better encodings for that), but it should not be part of how the plaintext is transformed for encryption.
Learn about AES-CTR (or AES-OFB, even though it's not nearly as common), which let you encrypt data without bothering forming 16-byte blocks (these two modes avoid the need for padding; on the other hand that would be necessary for ECB, a mode of operation notorious for being bad, especially for highly redundant plaintext including uncompressed images).
Your padding scheme should come with a means to identify what parts of the message are padding and then remove them. One possible scheme is if the last block is 1-15 bytes long, pad out all but the last byte with zeros and then write the length into the last byte, but if the last block is 16 bytes add another block of all zeros.
Upon decrypting, put in an extra "remove padding step" that reads the last byte as a number $n\in 0,\ldots,15$ and then discard the last $16-n$ bytes.