Unless MySQL does something strange, using only ASCII characters (i.e. only values 0 - 127) should be the exact same encoding, and hence the exact same size, between ASCII, UTF-8, and many other 8-bit code pages. It's only when you hit code points above 127 (or 0x7F) that UTF-8 starts to require additional space (though technically speaking, standard ASCII ...
The one reason I can see is that you are doing unnecessary work that way. PostgreSQL will compress and toast the base64 string, so you have to pay the price of compression and decompression, unless you set the column to EXTERNAL, then you don't compress, but you waste storage space and I/O bandwidth.
Hint: if you store compressed binary data in PostgreSQL, ...
Individual PostgreSQL fields over 2000 bytes are automatically compressed, for TOAST storage. However, this compression is not very good, and is local to just that one PostgreSQL value, so can't compress out repetition that occurs between values (like the same keys being used repeatedly, but only once in each JSON structure). You might want to look at ZSON ...
Try dumping using --hex-blob
mysqldump --hex-blob test_db test > dump_test.sql
mysqldump --hex-blob --no-create-info test_db test > dump_test2.sql
Please let us know if the hex value remains the same between the two dumps.
UPDATE 2021-01-08 14:15 EST
Try changing character set
The MySQL Docs say that mysqldump will use utf8 if not specified
Forcing a BOM and UTF-16 encoding for redirected output can be done somehow by Windows shells (personally I've experienced this with Powershell and Windows 10).
See e.g. Resolve UTF-8, UTF-16, ASCII inconsistencies for some context.
In the case of pg_dump, using the -f option to specifiy the output file instead of a shell redirection seems like a good idea ...
To escape all special char except NULL, new line and tab:
select * .. | mysql ... | sed 's/[\x04-\x08\x0B-\x1F\x7F]/ /g' > /tmp/file
The Fiddle is wrong.
あ A い I う U え E お O.
is 20 characters / 40 bytes when declaring that the client is encoded in utf8 (or utf8mb4). But if you claim that that it is in latin1, it leads to Mojibake or "double-encoding", hence the 30 and 48 that Fiddle shows.
あ A い I う U え E お O. --> E38182 41 E38184 49 E38186 55 E38188 45 E3818A 4F 2E
For further ...