colorama: Simple cross-platform Python API for colored terminal text

Announcing new Python package, colorama:

ANSI escape character sequences have long been used to produce colored terminal text on Unix and Macs. Colorama makes this work on Windows, too. It also provides some shortcuts to help generate these ANSI sequences, and works fine in conjunction with any other ANSI sequence generation library, such as Termcolor (

This has the upshot of providing a simple cross-platform API for printing colored terminal text from Python, and has the happy side-effect that existing applications or libraries which use ANSI sequences to produce colored output on Linux or Macs can now also work on Windows, simply by calling colorama.init().

I realise that printing colored terminal text is verging on pathalogically superficial, but it has long irked me that this didn’t just work. Python should make this easy.

My mapping of ANSI conventions to the equivalent Win32 calls is far from perfect. Currently it has the following results. ANSI codes under Ubuntu on gnome-terminal:

and the exact same ANSI codes printed on Windows under Colorama:

Update: I previously wrote here about discrepancies between the two, which have since been fixed. The only outstanding issue is that colorama does not support ‘dim’ text on Windows – it looks just the same as ‘normal’ text, and as far as I know, will never be able to.

5 thoughts on “colorama: Simple cross-platform Python API for colored terminal text

  1. Pingback: : More Colored Terminal text on Windows: AnsiCon

  2. Thanks heaps for the encouragement Juho and John.

    Thanks also to Lennart. I really want to chat to people about this mapping, so your thoughts are very much wanted. But thus far I think we’re both just a bit confused. :-)

    The illegible settings you describe only apply when printing black text on a black background (top left of the grids above.) When printing white text on a black background (top right of grids), all is visible on both UNIX and Windows.

    Currently my mapping is:

    ANSI dim -> Win dim fore on dim back
    ANSI normal -> Win bright fore on dim back
    ANSI bright -> Win bright fore on bright back

    However, using bright backgrounds might look messy on applications that don’t expect the background brightness to change, so I’m considering doing what you say anyway.

    The problem is that there are two possibilities, both of which are also flawed:

    ANSI dim -> (same as ‘ANSI normal’)
    ANSI normal -> Win dim fore on dim back
    ANSI bright -> Win bright fore on dim back
    (ie. no longer support ‘dim’, and ANSI normal comes out as dim text, which is probably rubbish)


    ANSI dim -> Win dim fore on dim back
    ANSI normal -> Win bright fore on dim back
    ANSI bright -> (same as ‘ANSI normal’)
    (ie. no longer support ‘ANSI bright’)

    I guess I’d choose the latter. Or maybe I could let it be configurable?

  3. Cool!

    I think it’s a problem that “normal” are illegible on Unix and legible on Windows, while “dim” and “bright” is legible on Unix and illegible on Windows.The problem is based on that you map “dim” to “normal” and “normal” to “bright”.

    I think it would be better to just map dim -> normal, and note that there is no dim setting on Windows, so don’t use it. :)

Leave a Reply