Access modifiers control who can see and use a class, field, method, or constructor. They are the enforcement mechanism for encapsulation — the OOP principle that says objects should control what data they expose and what stays internal.

Java has four access levels. Three are keywords: private, protected, and public. The fourth has no keyword — it is the default level that applies when you write nothing, often called package-private. Choosing the right access level is not cosmetic — it determines what code can change, who can extend what, and how tightly coupled your classes become over time.

The Four Access Modifiers at a Glance

Modifier	Keyword	Accessible From
Private	`private`	Same class only
Default (Package-Private)	(none)	Same class + same package
Protected	`protected`	Same class + same package + subclasses (any package)
Public	`public`	Everywhere — any class, any package

This is the visibility ladder — each level adds more access than the one above it. private is the most restrictive; public is the most open.

What Can Access Modifiers Be Applied To?

Access modifiers can be applied to four Java constructs, but not all modifiers are valid on all constructs.

Construct	private	default	protected	public
Top-level class	No	Yes	No	Yes
Nested class	Yes	Yes	Yes	Yes
Field	Yes	Yes	Yes	Yes
Method	Yes	Yes	Yes	Yes
Constructor	Yes	Yes	Yes	Yes

A top-level class can only be public or package-private (default). Making a top-level class private or protected is a compile-time error — it makes no logical sense since there would be no way to access it.

private — Maximum Encapsulation

The private modifier restricts access to within the declaring class only. No other class — not even a subclass or a class in the same package — can access a private member.

Private is the default choice for all fields in production Java. The field is protected, and access is controlled through public methods.

Java

// File: BankAccount.java

public class BankAccount {

    // Private fields — no class outside BankAccount can read or write these directly
    private final String accountNumber;
    private double       balance;
    private int          failedLoginAttempts;

    public BankAccount(String accountNumber, double initialDeposit) {
        this.accountNumber      = accountNumber;
        this.balance            = Math.max(0.0, initialDeposit);
        this.failedLoginAttempts = 0;
    }

    // Controlled read access
    public double getBalance() {
        return balance;
    }

    public String getAccountNumber() {
        return accountNumber;
    }

    // Controlled write access with business rule
    public boolean deposit(double amount) {
        if (amount <= 0) return false;
        balance += amount;
        return true;
    }

    public boolean withdraw(double amount) {
        if (amount <= 0 || amount > balance) return false;
        balance -= amount;
        return true;
    }

    // Private helper — internal logic, not exposed to callers
    private boolean isBalanceSufficient(double amount) {
        return balance >= amount;
    }
}

Java

// File: PrivateDemo.java

public class PrivateDemo {

    public static void main(String[] args) {

        BankAccount account = new BankAccount("ACC-2024-001", 10000.0);

        System.out.println("Balance: Rs." + account.getBalance());
        account.deposit(5000.0);
        System.out.println("After deposit: Rs." + account.getBalance());

        boolean success = account.withdraw(3000.0);
        System.out.println("Withdrawal Rs.3000 succeeded: " + success);
        System.out.println("Final balance: Rs." + account.getBalance());

        // account.balance = 999999; // compile error — private field
        // account.isBalanceSufficient(100); // compile error — private method
    }
}

Output:
Balance: Rs.10000.0
After deposit: Rs.15000.0
Withdrawal Rs.3000 succeeded: true
Final balance: Rs.12000.0

The balance field is completely protected. External code cannot set it to an arbitrary value — every change goes through deposit() or withdraw(), which enforce business rules. The isBalanceSufficient() helper is also private — it is an implementation detail that the caller has no reason to know about.

default (Package-Private) — Collaboration Within a Package

When no modifier is written, the member has default access — also called package-private. It is accessible from any class in the same package but invisible to classes in other packages, including subclasses in other packages.

Default access is the right choice for classes and members that are implementation details of a package but need to collaborate with other classes in that package.

Java

// File: com/devstackflow/payment/PaymentValidator.java

package com.devstackflow.payment;

// Default class — accessible only within com.devstackflow.payment
class PaymentValidator {

    // Default method — visible to other classes in the same package
    boolean isValidAmount(double amount) {
        return amount > 0 && amount <= 500000.0;
    }

    boolean isValidUpiId(String upiId) {
        return upiId != null && upiId.contains("@");
    }
}

Java

// File: com/devstackflow/payment/PaymentService.java

package com.devstackflow.payment;

public class PaymentService {

    // PaymentValidator is default — accessible because same package
    private final PaymentValidator validator = new PaymentValidator();

    public String processPayment(String upiId, double amount) {
        if (!validator.isValidUpiId(upiId)) {
            return "FAILED: Invalid UPI ID — " + upiId;
        }
        if (!validator.isValidAmount(amount)) {
            return "FAILED: Invalid amount — Rs." + amount;
        }
        return "SUCCESS: Rs." + amount + " sent to " + upiId;
    }
}

Java

// File: PaymentDemo.java

import com.devstackflow.payment.PaymentService;

public class PaymentDemo {

    public static void main(String[] args) {

        PaymentService service = new PaymentService();

        System.out.println(service.processPayment("rahul@upi", 1500.0));
        System.out.println(service.processPayment("invalid-id", 1500.0));
        System.out.println(service.processPayment("priya@upi", -200.0));

        // PaymentValidator validator = new PaymentValidator(); // compile error — outside package
    }
}

Output:
SUCCESS: Rs.1500.0 sent to rahul@upi
FAILED: Invalid UPI ID — invalid-id
FAILED: Invalid amount — Rs.-200.0

PaymentValidator is an internal detail of the com.devstackflow.payment package. No code outside the package can see or instantiate it. PaymentService — which is public — is the only entry point. This is the standard pattern for package-level encapsulation in real Java projects.

protected — Inheritance-Aware Access

The protected modifier allows access from the same class, the same package, and any subclass — regardless of which package the subclass lives in. It is designed for inheritance scenarios where a parent class needs to share implementation details with child classes without exposing them to the entire world.

Java

// File: com/devstackflow/notification/BaseNotification.java

package com.devstackflow.notification;

public abstract class BaseNotification {

    private final String notificationId;
    private final String recipientId;

    // Protected — subclasses can read this but external code cannot
    protected final String message;
    protected final int    priority;

    public BaseNotification(String notificationId, String recipientId,
                            String message, int priority) {
        this.notificationId = notificationId;
        this.recipientId    = recipientId;
        this.message        = message;
        this.priority       = priority;
    }

    public String getNotificationId() { return notificationId; }
    public String getRecipientId()    { return recipientId; }

    // Protected method — shared implementation detail for subclasses
    protected String buildBasePayload() {
        return "[P" + priority + "] To: " + recipientId + " | " + message;
    }

    // Abstract — each subclass provides its own delivery
    public abstract void deliver();
}

Java

// File: com/devstackflow/sms/SmsNotification.java
// Note: different package from BaseNotification

package com.devstackflow.sms;

import com.devstackflow.notification.BaseNotification;

public class SmsNotification extends BaseNotification {

    private final String phoneNumber;

    public SmsNotification(String notificationId, String recipientId,
                           String phoneNumber, String message) {
        super(notificationId, recipientId, message, 2);
        this.phoneNumber = phoneNumber;
    }

    @Override
    public void deliver() {
        // Subclass can access protected fields and methods from parent
        String payload = buildBasePayload(); // protected method — accessible in subclass
        System.out.println("SMS to " + phoneNumber + ": " + payload);

        // Accessing protected field directly
        if (priority == 1) {
            System.out.println("  [URGENT] Immediate delivery triggered.");
        }
    }
}

Java

// File: ProtectedDemo.java

import com.devstackflow.sms.SmsNotification;

public class ProtectedDemo {

    public static void main(String[] args) {

        SmsNotification sms = new SmsNotification(
                "NOTIF-001", "USER-9876",
                "9876543210", "Your OTP is 847291. Valid for 5 minutes."
        );

        sms.deliver();

        // sms.message         // compile error — protected, not a subclass here
        // sms.buildBasePayload() // compile error — protected, not a subclass here
    }
}

Output:
SMS to 9876543210: [P2] To: USER-9876 | Your OTP is 847291. Valid for 5 minutes.

SmsNotification is in a completely different package from BaseNotification, yet it can access message, priority, and buildBasePayload() because it is a subclass. ProtectedDemo — which is not a subclass — cannot access these members even though it is in the calling code.

public — Unrestricted Access

The public modifier makes a member accessible from any class in any package. Public is the right choice for APIs — the interface your class presents to the outside world. Everything that is not part of the public API should be something more restrictive.

Java

// File: PricingService.java

public class PricingService {

    // Public constants — part of the API, callers are allowed to read these
    public static final double GST_RATE              = 0.18;
    public static final double FREE_DELIVERY_MINIMUM = 299.0;

    // Public method — the API callers use
    public double calculateTotal(double itemTotal, boolean includeDelivery) {
        double gst          = itemTotal * GST_RATE;
        double deliveryFee  = resolveDeliveryFee(itemTotal, includeDelivery);
        return itemTotal + gst + deliveryFee;
    }

    // Private — internal detail, not part of the public API
    private double resolveDeliveryFee(double itemTotal, boolean includeDelivery) {
        if (!includeDelivery) return 0.0;
        return itemTotal >= FREE_DELIVERY_MINIMUM ? 0.0 : 40.0;
    }
}

Java

// File: PublicDemo.java

public class PublicDemo {

    public static void main(String[] args) {

        PricingService pricing = new PricingService();

        double total1 = pricing.calculateTotal(250.0, true);
        double total2 = pricing.calculateTotal(350.0, true);

        System.out.printf("Order Rs.250 total (with delivery): Rs.%.2f%n", total1);
        System.out.printf("Order Rs.350 total (free delivery): Rs.%.2f%n", total2);
        System.out.println("GST rate: " + (PricingService.GST_RATE * 100) + "%");
    }
}

Output:
Order Rs.250 total (with delivery): Rs.335.00
Order Rs.350 total (free delivery): Rs.413.00
GST rate: 18.0%

calculateTotal() is public — callers use it. resolveDeliveryFee() is private — it is a helper that the caller has no business knowing about. If the delivery fee structure changes internally, no external code breaks because the caller only depends on calculateTotal().

Access Modifiers — Detailed Visibility Table

The table below shows exactly which contexts can access each modifier level. Use this as a quick reference.

Access Level	Same Class	Same Package (non-subclass)	Subclass (different package)	Any Other Class
`private`	Yes	No	No	No
default	Yes	Yes	No	No
`protected`	Yes	Yes	Yes	No
`public`	Yes	Yes	Yes	Yes

private vs default vs protected vs public

Aspect	private	default	protected	public
Keyword	`private`	(none)	`protected`	`public`
Same class	Yes	Yes	Yes	Yes
Same package	No	Yes	Yes	Yes
Subclass (other package)	No	No	Yes	Yes
Unrelated class (other package)	No	No	No	Yes
Typical use	Fields, helpers	Package internals	Inherited behaviour	Public API
Encapsulation strength	Strongest	Strong	Moderate	None

When to Use Each Access Modifier

Situation	Recommended Modifier	Reason
Class fields	`private`	All field access goes through methods — encapsulation
Public API methods	`public`	Callers outside the class need to use them
Internal helper methods	`private`	No caller outside the class needs them
Package-level implementation classes	default	Visible within package, hidden from outside
Methods shared with subclasses	`protected`	Inheritance needs access, world does not
Constants meant for all callers	`public static final`	API-level shared constant
Constructors for singletons	`private`	Prevents direct instantiation
Template method steps in abstract class	`protected`	Subclasses override them, callers do not call them

Real-World Example — Logistics Tracking System

The Business Problem

You are building the shipment tracking backend for a logistics company — similar to what Delhivery or Ekart runs for its package movement system. The system has a base Shipment class with internal tracking state, a PriorityShipment subclass that can access certain parent internals for priority processing, and a TrackingService that the outside world uses through a public API. Each layer must see exactly what it needs and no more.

Implementation

Java

// File: com/devstackflow/logistics/Shipment.java

package com.devstackflow.logistics;

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;

public class Shipment {

    // Private — internal identity, no caller needs to set this
    private final String shipmentId;

    // Private — tracking history is internal state
    private String currentStatus;
    private String currentLocation;

    // Protected — subclasses need to read these for priority handling
    protected final String destinationCity;
    protected final double weightKg;
    protected       int    deliveryAttempts;

    // Default — accessible within the logistics package for internal services
    LocalDateTime estimatedDelivery;

    public Shipment(String shipmentId, String destinationCity, double weightKg) {
        this.shipmentId        = shipmentId;
        this.destinationCity   = destinationCity;
        this.weightKg          = weightKg;
        this.currentStatus     = "BOOKED";
        this.currentLocation   = "Origin Hub";
        this.deliveryAttempts  = 0;
        this.estimatedDelivery = LocalDateTime.now().plusDays(3);
    }

    // Public — callers use this to track status
    public String getShipmentId()    { return shipmentId; }
    public String getCurrentStatus() { return currentStatus; }
    public String getCurrentLocation(){ return currentLocation; }

    // Protected — subclasses can update status during processing
    protected void updateStatus(String status, String location) {
        this.currentStatus   = status;
        this.currentLocation = location;
    }

    // Private helper — internal only
    private String formatDateTime(LocalDateTime dt) {
        return dt.format(DateTimeFormatter.ofPattern("dd-MM-yyyy HH:mm"));
    }

    // Public — callers use this for the tracking summary
    public String getTrackingSummary() {
        return shipmentId + " | " + currentStatus
                + " | Location: " + currentLocation
                + " | ETA: " + formatDateTime(estimatedDelivery);
    }
}

Java

// File: com/devstackflow/logistics/PriorityShipment.java

package com.devstackflow.logistics;

public class PriorityShipment extends Shipment {

    private final String priorityLevel;
    private final String dedicatedCourierId;

    public PriorityShipment(String shipmentId, String destinationCity,
                            double weightKg, String priorityLevel,
                            String dedicatedCourierId) {
        super(shipmentId, destinationCity, weightKg);
        this.priorityLevel      = priorityLevel;
        this.dedicatedCourierId = dedicatedCourierId;
        // Override default ETA for priority shipments — accesses package-default field
        this.estimatedDelivery  = java.time.LocalDateTime.now().plusHours(24);
    }

    public void attemptDelivery(String hubLocation) {
        deliveryAttempts++;    // protected field — accessible in subclass
        if (deliveryAttempts <= 3) {
            // Protected method — subclass calls parent's protected method
            updateStatus("OUT_FOR_DELIVERY", hubLocation);
            System.out.println("[" + priorityLevel + "] Attempt "
                    + deliveryAttempts + " from " + hubLocation
                    + " by courier " + dedicatedCourierId);
        } else {
            updateStatus("DELIVERY_FAILED", hubLocation);
            System.out.println("Delivery failed after " + deliveryAttempts + " attempts.");
        }
    }

    public boolean isHeavyShipment() {
        return weightKg > 10.0; // protected field — directly accessible
    }
}

Java

// File: TrackingDemo.java

import com.devstackflow.logistics.PriorityShipment;
import com.devstackflow.logistics.Shipment;

public class TrackingDemo {

    public static void main(String[] args) {

        Shipment standard = new Shipment("SHP-001", "Chennai", 2.5);
        PriorityShipment priority = new PriorityShipment(
                "SHP-002", "Mumbai", 15.0, "EXPRESS", "DRV-4521"
        );

        System.out.println("=== Tracking Report ===\n");
        System.out.println(standard.getTrackingSummary());
        System.out.println(priority.getTrackingSummary());

        System.out.println("\n--- Priority Delivery Attempts ---");
        priority.attemptDelivery("Andheri Hub");
        System.out.println(priority.getTrackingSummary());
        System.out.println("Heavy shipment: " + priority.isHeavyShipment());

        // priority.weightKg         // compile error — protected, not a subclass here
        // priority.estimatedDelivery // compile error — default, different package
        // priority.updateStatus(...) // compile error — protected, not a subclass here
    }
}

Output:
=== Tracking Report ===

SHP-001 | BOOKED | Location: Origin Hub | ETA: 18-01-2024 10:30
SHP-002 | BOOKED | Location: Origin Hub | ETA: 16-01-2024 10:30

--- Priority Delivery Attempts ---
[EXPRESS] Attempt 1 from Andheri Hub by courier DRV-4521
SHP-002 | OUT_FOR_DELIVERY | Location: Andheri Hub | ETA: 16-01-2024 10:30
Heavy shipment: true

Each access level does exactly what it should. private fields like shipmentId are completely hidden. protected fields like weightKg and deliveryAttempts are accessible to PriorityShipment for its processing logic. The default field estimatedDelivery is accessible within the logistics package for internal coordination. The public API — getTrackingSummary(), getShipmentId() — is what external callers use.

Best Practices

Start with private — open up only when there is a reason

The discipline is to make everything private first, then consciously decide to widen access only when a genuine need exists. Opening access is easy; closing it after other code depends on it is painful. Teams following clean architecture treat any non-private field as a design decision that requires justification in a code review.

Never make fields public

A public field gives any code in any package the ability to set it to any value without going through any validation. If the field needs to be readable, add a getter. If it needs to be writable, add a setter with validation. A mistake that appears often in fresher pull requests is making fields public to avoid writing getters — this trades a few lines of code for a complete loss of encapsulation.

Use protected deliberately — not as a lazy alternative to private

protected exists specifically for inheritance. If you are making a member protected for a reason other than "subclasses need it," reconsider. Protected members become part of your class's contract with subclasses — changing or removing them later breaks every subclass, even ones written by other teams.

Prefer package-private for internal collaborators

When two classes in the same package need to work together closely but the collaboration should not be visible to the outside world, default access is the right tool. It is more restrictive than protected but allows package-level collaboration.

Common Mistakes

Mistake 1 — Making Fields public

Java

// Wrong — any code anywhere can corrupt this data
public class UserProfile {
    public String username;  // no validation possible
    public int    age;       // can be set to -500
    public String email;     // can be set to anything
}

// Correct — fields are private, access is controlled
public class UserProfile {
    private String username;
    private int    age;
    private String email;

    public void setAge(int age) {
        if (age < 0 || age > 120) throw new IllegalArgumentException("Invalid age: " + age);
        this.age = age;
    }
}

Mistake 2 — Confusing protected with package-private

Java

// Developer expects protected to behave like private outside the package
// But a subclass in ANY package can access protected members

package com.other.package;

import com.devstackflow.logistics.Shipment;

public class RogueSubclass extends Shipment {

    public RogueSubclass() {
        super("HACK-001", "Unknown", 0.0);
    }

    public void expose() {
        // This compiles and runs — protected members are visible to ALL subclasses
        System.out.println("Weight: " + weightKg); // protected field — accessible
        updateStatus("TAMPERED", "Unknown");        // protected method — accessible
    }
}

protected does not mean "accessible only to subclasses in my package." It means "accessible to all subclasses everywhere." Any developer who extends your class gains access to all its protected members. During code reviews, seniors commonly flag unnecessary protected on members that should have been private.

Mistake 3 — Using public for Everything

Java

public class OrderProcessor {

    public double taxRate     = 0.18; // should be private static final
    public String lastOrderId = "";   // should be private

    public double calculateTax(double amount) { return amount * taxRate; }
    public void   logOrder(String id)         { this.lastOrderId = id; }
    public boolean validateAmount(double amt) { return amt > 0; } // internal helper
}

Every method and field being public means any code anywhere depends on all of them. Changing taxRate from double to BigDecimal for precision, or removing logOrder() because it was replaced with a logging framework, now breaks callers you did not know existed. Minimal public API means fewer unintended dependencies.

Mistake 4 — Trying to Apply private or protected to a Top-Level Class

Java

// Compile error — top-level classes can only be public or default
private class InternalService { }   // error
protected class SharedHelper  { }   // error

// Correct options for top-level classes
public class InternalService { }    // visible everywhere
class SharedHelper            { }   // visible within the package only

Only nested classes can use private or protected. Top-level classes have only two options: public or package-private (default). If you need a class to be private to its enclosing class, make it a nested class.

Interview Questions

Q1. What are the four access modifiers in Java and what is their visibility?

Java has private (same class only), default/package-private (same class and same package), protected (same class, same package, and any subclass in any package), and public (everywhere). They form a visibility ladder — each level adds access on top of the one before it. private is the most restrictive and public is the most open. The default level has no keyword — writing nothing applies it.

Q2. What is the difference between protected and default (package-private) access?

Both allow access within the same class and same package. The difference is subclass access: protected members are visible to subclasses in any package, while default members are not accessible to subclasses outside the package. Use protected when inheritance is the reason for sharing — for template methods and hook points that subclasses need to override or call. Use default when the sharing is purely a package-level implementation concern with no inheritance relationship involved.

Q3. Can a private member of a class be accessed by its subclass?

No. Private members are accessible only within the declaring class itself. Subclasses do not inherit private members — they exist in the parent's objects but the subclass code cannot reference them directly. If a subclass needs access to parent state, the parent must expose it through a protected or public method. This is the correct design — the parent controls what the subclass can see.

Q4. Why should fields almost always be private in Java?

A public field allows any code anywhere to read or write the field value without going through any validation or control logic. A private field forces all access through methods, which can enforce business rules, trigger side effects, and maintain invariants. If the internal storage representation changes — from int to long, or from an array to a List — a private field with public methods allows that change without breaking callers. A public field embeds the implementation detail into every caller.

Q5. What is the difference between private and protected for a constructor?

A private constructor prevents any class — including subclasses — from instantiating the class directly. It is used for singleton patterns and utility classes. A protected constructor allows subclasses to call it using super() but prevents direct instantiation from unrelated classes. Abstract classes often use protected constructors — they must be subclassed to be used, and the constructor is there for subclass initialisation, not for direct external use.

Q6. What happens when you do not write any access modifier on a class member?

The member gets default (package-private) access. It is accessible from any class within the same package but invisible to classes in other packages, even subclasses. This is not public by accident — it is a deliberate, useful access level for package-internal collaboration. Teams often use it for classes and methods that support a public-facing class within the same package without being part of the external API.

FAQs

What are access modifiers in Java?

Access modifiers are keywords that control the visibility of a class, field, method, or constructor. Java has four: private (same class only), default/package-private (same package), protected (same package plus subclasses), and public (everywhere). They are the primary mechanism for implementing encapsulation.

What is package-private in Java?

Package-private is the access level that applies when no modifier keyword is written. A package-private member is visible to all classes in the same package but invisible to classes outside the package — including subclasses in other packages. It is not a keyword; the absence of a modifier keyword is what activates it.

Can a class be private in Java?

A top-level class cannot be private or protected — only public or default. A nested class (a class declared inside another class) can be private, which makes it visible only within the outer class. private nested classes are commonly used for implementation helpers that should not be exposed even at the package level.

What is the difference between private and protected in Java?

private restricts access to the declaring class only — subclasses cannot access it. protected allows access from the same class, same package, and any subclass anywhere. Use private for internal implementation details that no one — not even subclasses — should touch. Use protected when inheritance is the intentional design and subclasses need to work with the member.

Should all fields be private in Java?

Yes, in almost all cases. Making fields private is the foundation of encapsulation. The only common exceptions are public static final constants — values that are inherently public by nature. Even then, teams sometimes make constants package-private if they are only needed within a module.

What access modifier should I use for methods in an abstract class?

Methods in an abstract class that subclasses must override are typically public or protected abstract. Methods that provide shared implementation for subclasses are typically protected. Methods that are purely internal helpers are private. The abstract class's public API — what callers use — should be public. The template method pattern specifically uses protected for the hook methods that subclasses override.

Summary

Access modifiers enforce the visibility contract of every class, field, method, and constructor in Java. The four levels — private, default, protected, and public — form a ladder from most restrictive to most open. The discipline of starting with private and opening up only when there is a genuine reason is what keeps codebases maintainable and prevents unintended coupling between components.

The most important practical rule is that fields should almost always be private, with access going through methods that can validate, control, and evolve the implementation without breaking callers. protected exists for inheritance and nothing else. public is for the external API that callers genuinely need. Default is for package-level collaboration that belongs inside a module but not in its public interface.

For interviews, be ready to reproduce the four-level visibility table from memory, explain the specific difference between protected and default with a concrete example, and articulate why private fields with public methods is the correct encapsulation pattern. These are the most consistently tested points across service-based and product-based Java interviews.

What to Read Next

Topic	Link
How encapsulation uses private fields and public methods to protect state	Encapsulation →
How inheritance determines which protected members a subclass can access	Inheritance →
How constructors use access modifiers for singleton and factory patterns	Constructors →
How interfaces define public contracts for abstraction	Interfaces →
How abstract classes use protected methods as template method hooks	Abstract Classes →