internal fragmentation
Imagine buying eggs only by the dozen. You need 10 eggs, but you must buy 12, so 2 sit unused in the carton. The carton is full as far as the shop is concerned — you cannot give those 2 slots back — yet 2 eggs' worth of space is wasted inside what you bought. Internal fragmentation is exactly this: memory wasted inside an allocated block because the block is bigger than what was actually needed.
Concretely, internal fragmentation appears whenever memory is handed out in fixed-size units. With fixed-size partitions, a 4 KB process placed in an 8 KB slot wastes the other 4 KB — that slack belongs to the process and cannot be used by anyone else. The same thing happens with paging: memory is given out a whole page (a frame) at a time, so the last page of a process is usually only partly used. A process needing 10 KB with 4 KB pages takes three pages (12 KB) and wastes 2 KB in its final page. The waste is sealed inside the allocation — hence internal.
Why it matters: internal fragmentation is the price of allocating in chunks rather than to-the-byte. It is the opposite of external fragmentation: external waste sits between blocks (unusable scattered holes), internal waste sits inside a block (slack you are charged for but cannot use). Paging trades away external fragmentation but accepts internal fragmentation as the cost — on average about half a page per process — which is usually a very good trade.
Page size 4 KB. A process needs 10 KB, so it gets 3 pages = 12 KB. The first two pages are full; the third holds only 2 KB of useful data and 2 KB of internal fragmentation that no one else can touch.
The slack inside the last page is internal fragmentation.
Smaller pages reduce internal fragmentation but enlarge the page table and add overhead; larger pages do the reverse. Page size is a deliberate trade-off, not a free win, and internal fragmentation is the cost side of it.