In reference to a private message, Limbic~Region, it sounds like you're more interested in bulking up the file to emulate a large download or a large disk load. There are some thoughts about this.

If jpg is your target format, bulking it up on disk is easy: write a simple small .jpg file, then append as much random binary garbage that you want after it. This will satisfy your desire to make the file bigger without having to go through some tedious guesstimate loop that makes more PIXELS to satisfy the requirements of more BYTES.

If your intent is to create a larger download, either for stress testing your system or for poisoning a bandwidth hog, then this is a bit trickier: I don't think any browsers are smart enough to parse the jpg as it reads it (and stops when it reaches the end of valid jpg data), but theoretically one could. If you give a 1x1 pixel image with a megabyte of junk following, the jpg parser could stop after the first hundred bytes and not bother reading or downloading the rest. You'd have to do some tests to ensure you're seeing that the whole thing is getting downloaded.

If someone's leeching your bandwidth by deeplinking your jpg on your server, and you replace it with a surrogate, I suggest NOT inflating the file to hurt the downloader, since you're ultimately paying the bandwidth on your side too. Make a 1x1 or a highly-compressed "bandwidth hog" image to replace the original.

With GD or ImageMagick, if you want to make more PIXELS to make a genuine image that happens to require more BYTES (disk or memory), then I suggest you create a small original, then use these APIs to create a "stretched" equivalent of it at larger dimensions. This will ensure the jpg parser must read the whole thing. An image that is all-white or all-red, like the previous examples, will compress VERY well, so you will have a lot of PIXELS that don't take much disk space.