The trick with PKCS#5 padding (or the nearly equivalent PKCS#7 padding) is that it ends with a byte that indicates the number of padding bytes that was added to the message. You'd add $1$ to $n$ bytes to the message, where $n$ is the block size (formally $n=8$ in PKCS#5, $n\le255$ in PKCS#7). The end result is a full block of plaintext so that it can be encrypted using ECB or (P)CBC, without resorting to ciphertext stealing.
To check the validity of the padded plaintext as prescribed by PKCS#5 (6.1.2 §5), first take the final byte value $v$ and check if it is in the range $1$ to $n$ inclusive. Then check if the $v-1$ bytes before that final byte also have this value $v$. During decryption those bytes would be removed leaving you with the message. That message may well end with one or more bytes with the same value.
Note that the above checks allow for padding oracle attacks, and thus should not be performed if the integrity of the ciphertext hasn't been established by the receiving party. If the plaintext size is known in advance, then the checks and unpadding can be skipped altogether. Alternatively, when and if it becomes necessary to remove the padding, we can take the last byte $v$, and remove the $((n-1+v)\bmod n)+1$ last bytes. When $n\ne8$ this deviates neither from PKCS#5 (since formally it applies to $n=8$ only) nor from PKCS#7 (since that leaves the padding removal unspecified). This avoids the padding oracle, but later tests of the plaintext can still be exploitable.
Beware that there is also a padding mode from the (withdrawn) ISO 10126
standard that allows for padding with a byte of any value before the final byte. Otherwise it is compatible with PKCS#5/7, including the alternative padding check of the above paragraph.
