Reading File as Byte Array
Fast recall
Quick revision
Core answer
Files.readAllBytes(path) when a file is known to be small and bounded; it returns all bytes and manages its internal file resource. For large or untrusted files, stream incrementally because one byte array needs contiguous heap space and has an array-size limit.
Interview-ready guide
Interview answer
Files.readAllBytes(path) reads a complete file into one byte[]. It opens, reads, and closes the file internally, and it returns the original bytes without applying a character encoding. It is convenient when the file is known to be small and the whole value is needed at once.
For example, a test fixture containing the bytes {1, 2, 3} can be read and compared directly with the expected array. A small certificate or binary configuration value can be handled in the same way. If the file is UTF-8 text and the required result is a String, Files.readString(path, UTF_8) makes the text decoding clearer.
The whole file must fit in heap memory as one Java array. Large or user-controlled data should instead be read from an InputStream or channel in fixed-size chunks, with a maximum enforced while the data is being consumed. transferTo or Files.copy can also move data without keeping the entire payload in one array.
readAllBytes can throw IOException for file-system errors and may fail when enough memory cannot be allocated. Checking Files.size(path) first can help with a limit, but it is only a snapshot because another process may change the file before it is read. Use this method for small, bounded inputs; use streaming for large, changing, uncertain, or incremental input.
Reading File as Byte Array
Direct Answer
Use Files.readAllBytes(path) when a file is known to be small and bounded; it returns all bytes and manages its internal file resource. For large or untrusted files, stream incrementally because one byte array needs contiguous heap space and has an array-size limit.
Deep Dive & Architecture
The live memory cost can exceed the file size. The returned byte array occupies the full payload, an API may copy it again, and decoding can allocate a String or character storage alongside it. Several concurrent requests multiply that footprint.
A stream allows backpressure and early decisions. A hash can update per chunk, an upload can stop after a configured maximum, and a parser can emit records without waiting for end of file. Streaming does not remove the need for limits; it makes them enforceable without whole-payload allocation.
File contents can change during either method. If a consistent snapshot matters, the storage layer must provide one or the producer must publish immutable files.
Code Example
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Arrays;
class ReadFileAsBytes {
public static void main(String[] args) throws Exception {
Path file = Files.write(Files.createTempFile("bytes-", ".bin"), new byte[] {1, 2, 3});
try {
byte[] contents = Files.readAllBytes(file);
System.out.println(Arrays.equals(contents, new byte[] {1, 2, 3}));
} finally {
Files.deleteIfExists(file);
}
}
}
Check your understanding
Answer these without looking back at the article.
- Does Files.readAllBytes need try-with-resources at the call site?
- Why is Files.size not a stable guarantee before reading?
- When should a file be processed as a stream instead?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.