The short answer
A browser fingerprint is a collection of observable browser characteristics: canvas and WebGL rendering, installed fonts, screen properties, language, timezone, browser version and similar signals. A device fingerprint is usually a product term for the identifier or device record an application builds from those observations and, sometimes, its own history.
Neither is a hardware serial number. A website cannot read an iPhone IMEI or a laptop motherboard ID through ordinary browser JavaScript. Both terms describe inferences from the environment a browser exposes. The important distinction is scope: the browser fingerprint is the measurement; device identity is the way an application interprets that measurement over time.
What goes into a browser fingerprint
Modern fingerprint collectors look across many independent surfaces. Canvas rendering reflects fonts, graphics libraries and rasterization. WebGL can expose a renderer, vendor and graphics limits. Audio processing can produce small numerical differences. The browser also reports languages, timezone, screen size, device pixel ratio, touch support and portions of its user agent.
The collector normally normalizes these values and hashes them. Hashing makes a long set of properties easier to compare, but it does not make the result inherently unique or anonymous. Two identical managed laptops may produce the same input, while one laptop can produce a different result after a browser or operating-system update.
How an application turns observations into device identity
An application can place the browser fingerprint in context. It can scope the identifier to one project, record when that identifier was seen, compare component changes, and examine the network used for the current event. That creates a practical device record without claiming access to a permanent physical identifier.
For example, a SaaS product may see the same project-scoped device ID return from a different IP after a customer moves from home Wi-Fi to mobile data. That continuity can be useful. If only a few common properties match, the product should treat the comparison as uncertain rather than quietly merging two users into one device.
Which term should developers use?
Use browser fingerprint when discussing the collection method or the observable values themselves. Use device ID or device record when discussing the identifier your product stores and the history associated with it. If a vendor says device fingerprint, check whether it means a raw browser hash, a probabilistic matching system, a first-party cookie, or a combination of all three.
Clear language matters because each system fails differently. Cookies can be deleted. Exact fingerprints can change. Similarity matching can join unrelated browsers if its threshold is too broad. A well-designed API exposes enough information to understand which path produced a match and leaves the application in control of the resulting action.
Privacy and appropriate use
Browser-derived identifiers can be personal data even when they do not contain a name. Collect them for a defined purpose, keep them scoped to the application that needs them and set a retention period. Security and fraud-prevention uses should still be documented, access-controlled and tested for disproportionate effects on shared or privacy-protected devices.
Do not describe a fingerprint match as proof that two accounts belong to the same human. It is evidence that the observed browser environments match or resemble each other. Combine it with account history and give legitimate users another route when the evidence leads to extra verification.