Nothing. That is the behavior. There is some justification for this. PNGs and JPGS have pixel dimensions, but do not really have resolution tags, since they are formats built for web display, which doesn't recognize inches. (This is simplification of a rabbit-hole of a subject). Say that someone creates a map at 140 pixels per grid, but someone else creates theirs at 280 pixels per grid, with the intent that they will spend much time at a higher screen magnification. If that map piece is 5x5 units, Roll20 doesn't know what the intent of the designer was. It just knows that the graphic (which might be a map tile, a token or a prop...) is 700x700 pixels or 1400x1400 pixels. Lacking the intent, it opts to use a default size (the ones you've noted above). For the token layer, it assumes that most things dropped there will be a one-square token, so it size the image to one unit, regardless of its original dimensions. For map layer, it really has absolutely noting to go by, so it assumes the most likely is a 3x3 tile. This would doubtless be different if Roll20 enforced a standard resolution for all graphics, but they have not, instead electing for people to repurpose "found" pieces, use items they have created themselves, opt for higher resolutions if they prefer, and so on. Some Marketplace creators helpfully put the intent of the unit size in the name of the piece: "Hallway 10x60" or somesuch. There has been talk of API solutions to dropping a token and having it parse the size from the name and resize upon drop. But I think there are some programmatic hurdles at this point that prevent it. Your best bet is to note the intended size, right click on the dropped piece and se the dimensions there.