Is this how padding can work? So for block ciphers you need a fixed size block.

If the plaintext length is not a multiple of the block length then you need to pad it.

One way you could do this is that for the last block you just pad the blocks with 0s or some random characters except for the last character of the last block which represents the number of characters padded.

Of course the problem is what happens when the plaintext is a multiple of the block length (i.e. fits exactly). In this case you just add a dummy block of 0s or 1s. Then when you decrypt you know that if you encounter such a dummy block then the previous block has no padding.
You normally want to use a fully invertible padding scheme, i.e. a padding scheme with an associated unpadding scheme such that $unpad(pad(X)) = X$ for every $X$.

Assuming you only append data at the end, and don't do different things depending on the content of the message, this means that you always have to append something, even if the message is already of the right length.

In your scheme, in the case of a message which has already the length of a multiple of the block length, you'll have to append a full block ending with a 16 (assuming a 16-byte block cipher like AES).
Your unpadding function then reads the last byte, and knows it has to strip off 16 bytes.

You shouldn't do any special-casing with a block of a certain structure only in the case of a full block appended.

But note that you should preferably use standardized schemes to help interoperability - for example PKCS#7-padding works just like your scheme, but with a bit different filling of the padded data. (This, just like your scheme, requires that the number of appended bytes is encodable in a byte, i.e. a block size of less than 256 bytes = 2048 bits. I'm not aware of any common block cipher with a larger block size, but you would need a different padding scheme in this case.)