A digital image has exactly one real dimension: how many pixels wide and how many tall. That is the whole of it. Everything else — inches, centimetres, dpi, ppi — is a statement about how large you would like it printed, and a printed size is not a property of a file.
What the DPI number in a file actually is
Most image formats have a field for resolution. It is metadata: a note, written alongside the pixels, saying "when printing, put this many of my pixels in each inch". Changing it changes the note. It does not change a single pixel.
So an image at 1,200 by 1,800 pixels is the same image whether its note says 72 or 300. Open the export dialog, type 300 where it said 72, and you have edited a comment.
This is why "can you send it at 300 dpi" is, strictly, an unanswerable request, and why answering it by editing the field satisfies the dialog and disappoints the printer. What the person means is "send me enough pixels", and that is a question with a real answer.
The one calculation
Pixels divided by dpi gives inches. That is the entire relationship, and rearranging it answers every version of the question.
Multiply the printed size you want by the density you need, and you have the pixels required. A 6 × 4 inch photograph at 300 dpi needs 1,800 × 1,200 pixels — which is 2.2 megapixels, comfortably inside any phone camera of the last fifteen years.
An A4 page at 300 dpi needs 2,480 × 3,508. A billboard needs far less density than any of this, because nobody stands six inches from a billboard, and print shops routinely work at 20 dpi for them.
Where 72 came from
The number is a fossil. Early Macintosh screens were built at 72 pixels per inch specifically so that a point in a document — 1/72 of an inch, the typographer's unit — mapped to exactly one screen pixel. Text at 12 point occupied 12 pixels, and what you saw was what you got.
That correspondence held for about a decade and has been false ever since. Screens now run anywhere from roughly 90 to over 500 pixels per inch, and the operating system scales the interface independently of all of it.
The 72 survives as the default value software writes into the resolution field when nothing better is known, which is what gives people the impression that images from the web are "72 dpi" and therefore unusable. They are not 72 dpi. They have a note saying 72, and they have however many pixels they have — which is the only thing that matters.
Screens, and the number that does matter there
On screen, dpi is irrelevant and device pixel ratio is not. A phone advertising a 390-point-wide viewport may have three physical pixels for each of those points, so an image displayed 390 wide needs to be around 1,170 pixels to look sharp on it.
This is the reason a picture that looks fine on a laptop looks soft on a phone, which is the opposite of what people expect. The phone has the denser screen.
The practical rule for the web is to supply about twice the display width, and stop there. Three times is visible only on the densest screens and costs the file size regardless of who is looking.
Upscaling, and why it adds nothing
Enlarging an image invents pixels by interpolating between the ones you have. It can produce a larger file that looks smoother, and it cannot produce detail that was never recorded, because the detail is not somewhere else — it does not exist.
Machine-learning upscalers are genuinely better at this, and it is worth being clear about what they do: they hallucinate plausible detail based on what similar images tend to look like. For a background texture that is fine. For a document, a face or a number plate it is inventing content, and the invented content is convincing, which is the dangerous part.
The short version
Count pixels, not dots per inch. For print, multiply the size you want by 300 and check you have that many. For the web, take the widest the image will ever be displayed and resize to about double it.
And if someone asks for 300 dpi, ask what size they are printing. The answer to that is a pixel count, which is a thing your file either has or does not.