How can i check a base64 string is a file(what type?) or not?

Many filetypes have a header (the first few bytes of the file) with some fixed information by which a file can be identified as a gz, png, pdf, etc.

So every base64 encoded gz file would also start with a certain sequence of base64 characters, by which it can be recognized.

A gzip-file always starts with the two byte sequence 0x1f 0x1b, which in base64 encoding is H4 plus a third character in the range of s to v.

The reason is, that every base64 character represents 6 bits of the original bytes, so the two bytes 0x1f 0x1b are encoded with two base64 characters (12 bits) plus the first 4 bits of the third character.

Based on that, I would say that’s no base64 encoded gzip that you show there.

other examples are:

• png

  starts with: 0x89 0x50 0x4e 0x47 0x0d 0x0a 0x1a 0x0a

  base64 encoded: iVBORw0KGg...

• jpg

  starts with: 0xFF 0xD8 0xFF 0xD0

  base64 encoded: /9j/4...

• gif

  starts with: GIF

  base64 encoded: R0lG

• tif

  a) little endian:
  starts with: 0x49 0x49 0x2A 0x00

  base64 encoded: SUkqA

  b) big endian:
  starts with: 0x4D 0x4D 0x00 0x2A

  base64 encoded: TU0AK

• flv

  starts with FLV

  base64 encoded: RkxW

• wav/avi/webp and others

  several audio/video/image/graphic -formats are base on RIFF(Resource Interchange Format)
  The common part is that all files start with RIFF

  base64 encoded: UklGR

  After the RIFFheader, you’ll find the specific format starting in the 4 bytes starting at the 9th byte.
  In the following _ is used as a placeholder for any character.

  wav
  starts with: RIFF____WAVE
  base64 encoded: UklGR______XQVZF

  webp
  starts with: RIFF____WEBP
  base64 encoded: UklGR______XRUJQ

  avi
  starts with: RIFF____AVI
  base64 encoded: UklGR______BVkkg

---

Regarding the specific example in the question:

in the updated question there’s a hint in the attached picture that

the data is first base32 encoded and then base64 encoded.

When we feed an online base32 decoder with the string given in the question (JA2HGSKBJI4DSZ2WGRAS...), we get:

H4sIAJ89gV4A/+1ZURaEIAi8SkfQ+1/O3f7MtEBfMgz9rC/diXmIA5hSzun3HNdBbgbtVP2v/2+LowM837wFHKxZbmE9pQfsLOaiLAL8kvIk4MBma17ufHQbIJCXoWNZZKGPWB5QljvXIuXOmm0SgLixJw8HRC8Tbmz7x5eIspypaZHSWbj8cAhdjli2WUkR1sv2dZmwXhZlDnIcCl0GyrFX6fKkBEBTBsq+9uY2Ecug2Rf0xtaJlNdYJuxjP9kcd1LOW/fQXtb1sd3fSTGXFTx3UjfGFx6uJGjeIAAA

It starts with H4s, so according to what I wrote about how to recognize file types in base64 encoding, it’s a base64 encoded gzip file.

This can be saved in a text file and then uploaded on base64decode.org where it will be converted into a gzip file. When you download and open that gzip file it contains a file with text like this:

00110000 00110000 00110001 00110001 00110000 00110001 00110000 00110000 00100000 00110000 00110000 00110001 00110001 00110000 00110001 00110000 00110001 00100000 ...

Conclusion for this case: The original string/file is a gzip file that was first base64 encoded and the base64 encoded part was again encoded with base32.