Serializable vs Externalizable in Java Serialization

Last updated: September 2026 — rewritten with a comparison table, code examples, and interview Q&A.

"Serializable vs Externalizable" is a favorite second-round interview question, especially for 3–5 year experienced roles. The interviewer isn't testing whether you've memorized two interfaces — they're testing whether you understand who controls the byte format and what that costs. If you haven't read the basics yet, start with what serialization is.

Serializable vs Externalizable: the differences

Feature	Serializable	Externalizable
Interface type	Marker interface — no methods	Two methods: writeExternal(), readExternal()
Who controls the format	The JVM (default protocol)	You (custom protocol)
Effort	Zero — just implement the interface	You hand-write the field logic
Constructor on deserialization	Not called	Public no-arg constructor is called (mandatory)
Performance	Slower — uses reflection	Faster — direct method calls, smaller streams
Customization	Optional private writeObject/readObject	Full control by design
transient keyword	Honored	Ignored — you choose what to write
When to use	Default choice, 95% of cases	Custom/compact formats, performance-critical paths

In code: Serializable

Automatic — the JVM handles everything:

public class AI implements Serializable {
    private String secret;

    public AI(String secret) { this.secret = secret; }
    public String getSecret() { return secret; }
}
// serialize
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("ai.ser"));
out.writeObject(new AI("secret"));
out.close();
// deserialize — no constructor runs
ObjectInputStream in = new ObjectInputStream(new FileInputStream("ai.ser"));
AI ai = (AI) in.readObject();

In code: Externalizable

You own the format — including the mandatory public no-arg constructor:

public class AI implements Externalizable {
    private String secret;

    public AI() { }   // MANDATORY: deserialization calls this
    public AI(String secret) { this.secret = secret; }

    @Override
    public void writeExternal(ObjectOutput out) throws IOException {
        out.writeObject(secret);   // you pick every field
    }

    @Override
    public void readExternal(ObjectInput in)
            throws IOException, ClassNotFoundException {
        secret = (String) in.readObject();
    }
}

Forget the public no-arg constructor and deserialization fails with InvalidClassException: no valid constructor — the single most-tested Externalizable fact.

Interview rapid-fire

• When would you actually choose Externalizable? — When the default format is too verbose or slow, or you need a custom wire format (e.g., only 2 of 10 fields, in a specific order).
• Can you partially customize Serializable instead? — Yes: declare private void writeObject(ObjectOutputStream) / readObject(ObjectInputStream). Best of both worlds for small tweaks.
• Does Externalizable respect transient? — No. You write the bytes yourself, so transient is meaningless there.
• Which is faster and why? — Externalizable: no reflection, direct calls, and you can write a tighter stream.
• Parent and child both Externalizable? — Child's writeExternal calls super.writeExternal(out); readExternal calls super.readExternal(in).

Java serialization: the complete series

• What is serialization in Java (with example)
• What is the Externalizable interface
• What is serialVersionUID
• transient keyword in Java