Which of the three operations should I reach for by default?

Padding, unless something about the destination makes the empty area unacceptable. It is the only one of the three that is lossless with respect to the picture: cropping deletes pixels permanently and enlarging invents them. If the bars are a problem, the question to ask is whether the composition survives a crop, not whether the padding can be made invisible.

Can I pad and crop at the same time to split the difference?

You can, but not here — this site adds area and never removes it, so a crop is a separate step somewhere else, before the file arrives. Doing it in that order is the right sequence anyway: decide what the picture is, then decide how much room it sits in.

The photograph is nearly square already. Is a two-pixel bar worth adding?

If something downstream is checking the proportion, yes, because nearly square fails an exact test. If nothing is checking, a two-pixel bar is invisible and the file is fine as it is. The readout shows the bar width before you commit, which is the figure that answers this.

Does padding make the file noticeably larger?

Larger in pixel count, rarely much larger in bytes. Flat colour compresses extremely well in both PNG and JPG, so adding a thousand rows of one value costs a fraction of what a thousand rows of photograph would. The estimated size beside the export button is computed from the actual composite rather than from the pixel count, so it reflects this.

Fitting a photograph to a square

Three operations reach a square and only one of them leaves the photograph alone. Knowing which cost you are paying is most of the decision.

Three ways to change a shape

A photograph has a proportion it was taken at and a destination has a proportion it expects. Closing that gap always costs something, and the three available operations charge in different currencies.

Crop

Remove rows or columns until what remains matches the target. The result is entirely photograph, edge to edge, at the original sampling density — nothing is softened and nothing is invented. What it costs is composition: a 3:2 frame cropped to 1:1 loses a third of its width, and whatever was in that third is gone from the file.

Enlarge

Scale the short axis until the proportion matches. This preserves every element of the composition and destroys the geometry of the subject, which is why nobody seriously proposes it for photographs of people or buildings. Scaling both axes and then cropping is a different thing and amounts to a crop with extra interpolation.

Pad

Leave the photograph exactly as it is and add area around it until the frame matches. Nothing is lost and nothing is invented; the cost is that the added area is visible and holds no picture. It is the only one of the three where the price is fully apparent in the result, which is a reasonable argument for making it the default.

The bars are inert. They carry no detail, they are not part of the photograph, and nothing downstream can recover a composition from them. A picture padded to a square is the same picture it was, in a larger file.
Padding cannot make a photograph fill a frame. If the destination expects the image edge to edge, the honest options are cropping or accepting a visible border — there is no third answer that costs nothing.

Which axis grows, and by how much

The arithmetic is short. Compare the photograph’s proportion with the target’s. If the picture is wider than the target wants, the height is what falls short, so the output height becomes the width divided by the target proportion and the bars appear above and below. If the picture is taller, the width is short, the output width becomes the height multiplied by the target, and the bars appear at the sides.

The bar width on the growing axis is half the difference, rounded to a whole pixel. Where the difference is odd, one bar is a pixel wider than the other; the tool puts the extra pixel on the trailing edge and reports the centre position it used.

Common inputs padded to 1:1, with the axis that grows
Input	Output	Bars
3000 × 2000 (3:2)	3000 × 3000	500 px above and below
2000 × 3000 (2:3)	3000 × 3000	500 px left and right
4032 × 3024 (4:3)	4032 × 4032	504 px above and below
1080 × 1350 (4:5)	1350 × 1350	135 px left and right
6000 × 1500 (4:1)	6000 × 6000	2250 px above and below

That last row is the case where padding stops being sensible. A panoramic frame padded to a square is three quarters empty, and at that point the destination is asking for something the photograph is not. Either the picture gets cropped or the destination gets a wide picture.

Choosing the fill

White is the conventional answer and it reads as deliberate on almost any surface. It is also the safest when the destination background is unknown, because a white border on a dark ground reads as a frame, whereas a dark border on a white ground can read as a rendering fault.

The sampled edge — the average of the outer eight pixels of the photograph, weighted by alpha — is the interesting option. On a picture with a flat sky, a plain wall or an even studio background, the bars disappear into the image and the result reads as a wider photograph rather than a padded one. On a picture with a busy or high-contrast edge, the average lands on a muddy mid-tone and the effect is worse than white would have been. The rail prints the colour it computed so the choice can be made on the number rather than on hope.

Transparent defers the decision entirely. The bars are written with an alpha of zero and whatever the file is placed on shows through, which is the right answer when the padded file is going into a layout rather than being looked at directly. It requires a PNG export, because a JPG has no alpha channel to hold it.

Questions about the operation

Which of the three operations should I reach for by default?: Padding, unless something about the destination makes the empty area unacceptable. It is the only one of the three that is lossless with respect to the picture: cropping deletes pixels permanently and enlarging invents them. If the bars are a problem, the question to ask is whether the composition survives a crop, not whether the padding can be made invisible.
Can I pad and crop at the same time to split the difference?: You can, but not here — this site adds area and never removes it, so a crop is a separate step somewhere else, before the file arrives. Doing it in that order is the right sequence anyway: decide what the picture is, then decide how much room it sits in.
The photograph is nearly square already. Is a two-pixel bar worth adding?: If something downstream is checking the proportion, yes, because nearly square fails an exact test. If nothing is checking, a two-pixel bar is invisible and the file is fine as it is. The readout shows the bar width before you commit, which is the figure that answers this.
Does padding make the file noticeably larger?: Larger in pixel count, rarely much larger in bytes. Flat colour compresses extremely well in both PNG and JPG, so adding a thousand rows of one value costs a fraction of what a thousand rows of photograph would. The estimated size beside the export button is computed from the actual composite rather than from the pixel count, so it reflects this.