Postfix to Infix Converter
Paste a postfix expression and get it back as readable infix — with the brackets that the notation needs, the fully bracketed version, and the stack shown at every step.
Step-by-step stack trace
| # | Token | Action | Stack of expressions |
|---|
The stack holds part-built expressions, not single symbols — that is the one real difference from the infix to postfix direction.
The postfix to infix conversion algorithm
Converting postfix to infix is the mirror of the forward direction, and it is simpler. There is no precedence comparison and no operator stack. Instead the stack holds part-built expressions, and each operator joins the top two into a bigger one.
- Read the postfix expression left to right. One token at a time, exactly one pass, no lookahead.
- If the token is an operand, push it. It goes on the stack as a complete, one-symbol expression.
- If the token is an operator, pop two expressions. The first one popped is the right operand; the second is the left. This order is not optional.
-
Join them and push the result back.
Build
left operator right, adding brackets where the grouping would otherwise be lost, then push that string onto the stack. - At the end, one expression remains. That is the infix form. If more than one is left, or the stack ran short, the postfix input was malformed.
Worked example: A B + C *
The stack is written with its top on the right.
| # | Token | Action | Stack |
|---|---|---|---|
| 1 | A | Operand — push | A |
| 2 | B | Operand — push | A B |
| 3 | + | Pop B (right), pop A (left), push A + B | A + B |
| 4 | C | Operand — push | A + B C |
| 5 | * | Pop C, pop A + B; + is weaker than *, so bracket it | (A + B) * C |
Result: (A + B) * C. Step 5 is where the whole problem lives — drop
those brackets and you get A + B * C, which is a different expression.
Why brackets come back
Postfix needs no brackets because the order of the symbols already fixes the order of evaluation. Infix has no such guarantee: it relies on precedence rules, so any grouping that disagrees with those rules has to be written down explicitly.
A sub-expression needs brackets when its operator binds more loosely than
the operator about to consume it — and also when the precedence is equal but the
side is wrong for the associativity. That second case is why
A B C - - converts to A - (B - C) and not
A - B - C.
The converter shows both. The fully bracketed form wraps every single operation and is what most textbook algorithms produce — it is never wrong, just noisy. The infix row keeps only the brackets that are actually load-bearing, which is what a human would write.
The operand-order trap
The first value you pop is the right operand. It has to be — the stack returns the most recent push first, and in postfix the right operand is written second, so it was pushed second.
| Postfix | Correct infix | Wrong (operands swapped) |
|---|---|---|
| A B - | A - B | B - A |
| A B / | A / B | B / A |
| A B ^ | A ^ B | B ^ A |
| A B + | A + B | B + A — same value, still wrong |
Addition and multiplication hide the bug because they commute. Test with subtraction or division and it shows up immediately.
Postfix to infix examples
| Postfix | Infix | Fully bracketed | Why |
|---|---|---|---|
| A B + | A + B | (A + B) | The simplest case |
| A B C * + | A + B * C | (A + (B * C)) | No brackets needed — precedence agrees |
| A B + C * | (A + B) * C | ((A + B) * C) | Addition must happen first |
| A B - C - | A - B - C | ((A - B) - C) | Left associative, so no brackets |
| A B C - - | A - (B - C) | (A - (B - C)) | Grouping fights associativity |
| a b c ^ ^ | a ^ b ^ c | (a ^ (b ^ c)) | Right associative, so no brackets |
| A B ^ C ^ | (A ^ B) ^ C | ((A ^ B) ^ C) | Left grouping on a right-associative operator |
| a b + c d - * | (a + b) * (c - d) | ((a + b) * (c - d)) | Both sides need brackets |
| A B C * + D E / - | A + B * C - D / E | ((A + (B * C)) - (D / E)) | Precedence already gives the right order |
Spotting an invalid postfix expression
Track the stack depth while you scan: every operand adds one, every binary operator removes one. Two rules catch every malformed input.
| Input | Problem | Caught by |
|---|---|---|
| A B + + | Operator with nothing to work on | Depth drops below 2 at an operator |
| A B C + | An operand never gets consumed | Depth ends at 2 instead of 1 |
| A B | No operator at all | Depth ends at 2 |
| A + B | That is infix, not postfix | Depth is 1 when + arrives |
| (A B +) | Brackets in a postfix expression | Postfix never contains brackets |
Complexity
O(n) time and O(n) space for n tokens. Every token is read once; every operator does two pops, one join and one push. The only subtlety is that the strings on the stack grow, so the total characters built is O(n) plus whatever brackets are added — still linear.
That matches the forward direction, which is unsurprising: both are one pass over the input with one stack.
Frequently asked questions
How do you convert postfix to infix?
Scan the postfix expression left to right with a stack. Push every operand as a one-symbol expression. When you meet an operator, pop the top two entries — the first popped is the right operand, the second is the left — join them as left operator right, wrap the result in brackets if the precedence needs it, and push it back. One expression is left at the end and that is the infix form.
Why do brackets appear when converting postfix to infix?
Postfix has no brackets because the symbol order alone fixes the evaluation order. Infix does not have that property, so wherever the postfix grouping disagrees with normal precedence, brackets are the only way to preserve it. A B + C * must become (A + B) * C, because A + B * C would multiply first.
Which operand is popped first?
The right one. The stack returns the most recently pushed value first, and in postfix the right operand is written second, so it is pushed second. Getting this backwards is the single most common bug — it silently inverts subtraction, division and exponentiation while leaving addition and multiplication looking correct.
What is the time complexity of postfix to infix conversion?
O(n) time for n tokens. Each token is read once, and each operator does a fixed amount of work: two pops, one join and one push. Space is O(n) for the stack, and the strings it holds total O(n) symbols plus the brackets added.
How do I know if a postfix expression is valid?
Track the stack depth as you scan: each operand adds one, each binary operator removes one. If the depth ever drops below two when an operator arrives, an operand is missing. If it ends at anything other than exactly one, the expression is malformed. The converter above runs this check and tells you which case failed.
Can the same method convert prefix to infix?
Yes, with one change: scan the prefix expression right to left instead of left to right, and pop the left operand first. Everything else — the stack, the joining, the bracketing — is identical.
Is postfix to infix the same as evaluating the expression?
No. Converting rebuilds a readable expression and works with variables like A and B. Evaluating produces a single number and needs every operand to be numeric. Both use a stack and one pass, which is why they are often taught together; the converter above does both when the operands happen to be numbers.