converting Java bitmap to byte array
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
When Android developers say "convert a bitmap to a byte array," they usually mean encode a Bitmap into an image format such as PNG or JPEG and then read the resulting bytes. The standard approach is to compress the bitmap into a ByteArrayOutputStream and call toByteArray().
The Standard Approach
Here is the basic pattern in Java:
This does three things:
- creates an in-memory byte stream
- encodes the bitmap into an image format
- returns the encoded bytes
Those bytes can then be uploaded, stored in a database, written to disk, or passed through an API.
Choose the Right Format
The output format matters more than many people realize.
PNG
- lossless
- preserves transparency
- often larger than JPEG
JPEG
- lossy
- smaller for photos
- does not preserve transparency
For JPEG, the quality number matters. Lower values reduce file size but also reduce image quality.
Full Example
This example shows both directions: encode to bytes and decode back to a bitmap.
Encoded Bytes vs Raw Pixel Bytes
Sometimes the requirement is not "save as JPEG or PNG" but "get raw pixel bytes." Those are different tasks.
The compression approach above gives you encoded image bytes. If you need raw pixel memory, you might copy pixels into a ByteBuffer instead.
Use raw bytes only if another part of the system expects raw pixel data. They are larger and not suitable as a drop-in replacement for standard image files.
Memory Considerations
Bitmaps can be large, and converting them to byte arrays duplicates data in memory. That matters on Android, especially with photos.
Practical ways to reduce memory pressure:
- downsample the bitmap before conversion
- choose JPEG instead of PNG for photos
- avoid converting oversized camera images on the main thread
If the source bitmap is much larger than the final upload or thumbnail size, resize first and then encode.
Run It Off the UI Thread
Compression and large memory allocations can block rendering if done on the main thread. Use a background thread, executor, or coroutine-backed Java interop path for nontrivial images.
Even if the code is only a few lines, the underlying work may be expensive for large bitmaps.
When Quality Is Ignored
One subtle point: the quality parameter affects JPEG and some other lossy formats, but for PNG it is effectively ignored because PNG is lossless. Developers sometimes keep changing the quality value on PNG output and wonder why the file size does not change much.
That behavior is normal and not a bug in the code.
Common Pitfalls
- Assuming the byte array contains raw pixels when
compressactually produces encoded PNG or JPEG data. - Choosing JPEG for an image that needs transparency. JPEG discards alpha information.
- Expecting the quality parameter to meaningfully affect PNG output. PNG is lossless, so quality is not the tuning knob there.
- Converting very large bitmaps on the UI thread and then blaming Android for jank or freezes.
- Forgetting that bitmap-to-byte-array conversion increases memory usage because both the bitmap and encoded bytes may exist at the same time.
Summary
- The standard bitmap-to-byte-array conversion uses
ByteArrayOutputStreamplusbitmap.compress(...). - PNG is lossless and preserves transparency, while JPEG is smaller for photo-like images.
- Encoded image bytes are different from raw pixel bytes.
- Large bitmap conversions should be done carefully to avoid memory spikes and UI stalls.
- Pick the format and quality settings based on the actual storage or transport requirement.

