base64 -d decodes, but says invalid input

If you do the reverse, you'll note that the string isn't complete:

$ echo '{"foo":"bar","baz":"bat"}' | base64
eyJmb28iOiJiYXIiLCJiYXoiOiJiYXQifQo=

$ echo "eyJmb28iOiJiYXIiLCJiYXoiOiJiYXQifQo=" | base64 -di
{"foo":"bar","baz":"bat"}

---

Extracts of Why does base64 encoding require padding if the input length is not divisible by 3?

What are Padding Characters?

Padding characters help satisfy length requirements and carry no meaning.

However, padding is useful in situations where base64 encoded strings are concatenated in such a way that the lengths of the individual sequences are lost, as might happen, for example, in a very simple network protocol.

If unpadded strings are concatenated, it's impossible to recover the original data because information about the number of odd bytes at the end of each individual sequence is lost. However, if padded sequences are used, there's no ambiguity, and the sequence as a whole can be decoded correctly.

The command-line tool is picky about the presence of padding characters. That string is 34 characters long, so there should be two = signs as padding at the end.

$ echo "eyJmb28iOiJiYXIiLCJiYXoiOiJiYXQifQ==" | base64 -di; echo
{"foo":"bar","baz":"bat"}