The N suffix is for clojure.lang.BigInt, which are created with (bigint) which was added in Clojure 1.3 and still work to this day (I did these examples in the

The N suffix is for clojure.lang.BigInt, which are created with (bigint) which was added in Clojure 1.3 and still work to this day (I did these examples in the latest 1.10.3 release) user=> (bigint "129110040087761027839616029934664535539337183380513") 129110040087761027839616029934664535539337183380513N user=> (type *1) clojure.lang.BigInt The Java-platform bigint is java.lang.BigInteger which are created with (biginteger) which was added in Clojure 1.0. Printing one of these will not include an N suffix: user=> (biginteger "129110040087761027839616029934664535539337183380513") 129110040087761027839616029934664535539337183380513 user=> (type *1) java.math.BigInteger Clojure BigInts are supposed to involve less unboxing and therefore be more performant. If you provide an integer literal that's too large to fit in a java.lang.Long, the reader will use a BigInt instead: user=> 129110040087761027839616029934664535539337183380513 129110040087761027839616029934664535539337183380513N user=> (type *1) clojure.lang.BigInt user=> 12345 12345 user=> (type *1) java.lang.Long If all this seems like a mess, well it sort of is. Clojure has a very strong commitment to backwards compatibility, so when the Clojure-specific big int representation was added, the old JDK-based one was not removed, because the operations that the two support are different.