OK - no blowing up - but a simple basic comment:
If you downscale a raster graphic (made of pixels) this doesn't make the pixels smaller, this decreases the number of pixels you use in your raster to make up the graphic.
Hence your intended target size - 64x32 - is a per-edge-pixel-COUNT - as in, it will be 64 pixels wide by 32 pixels tall.
This means that you are going the other direction from your request - that is, the pixel-density (aka resolution) is going down as you scale your graphic, not up.
The use case in which shrinking an image down pushes up the pixel density is printing, in which yes, you can push the pixel density upwards to whatever the high end limit of the target printer is - often in excess of 300 DPI, some go well over 600 DPI.
If you scale your image in Photoshop, Gimp, Affinity Photo etc, but keeping in the same 72 PPI for-web file, you will see it resample the image once scaled and see the resolution drop drastically; similarly, if you export out from your native file as .png and force the export dimensions down to your target size, then open the resulting file in an image viewer or Gimp, you will see directly what happens: giant pixels relative to your image - you know - Minecraft style!
Maybe this will help this make more sense - I threw it together pretty quickly, but I think it should do:
Here's my image at original resolution (10x16 pixels) the red grid marks my pixels:
I downscale the image to 5x4 pixels, and in this process the pixels remain the same size (cos that's what pixels do - they're always the same size on a given display) and the software analyzes groups of four pixels to determine the new pixel in that relative location - hence the loss of details and subtlety of colour treatments when you drop pixel counts.
Hopefully this helps you wrap your head around it a bit more.