I second this.
I hate emoji for a very long time...

Interesting. There is an open issue for raw output with --raw. As of now we thought that it would also hide the progress bar, but now I'm thinking that it could be on by default and disabled with --no-progress. It would also remove the colors. Would that work for you?

Regarding the --raw (#271) I think it covers a slightly different use-case: --raw I think is meant to allow lychee to be integrated into an automated workflow, where there is no user waiting at the terminal, thus there is no need for the progress bar or the fancy messages; also the output should be more tailored towards machine parsing, but without going full-blown JSON. (In fact I think this mode could be actually called --quiet based on the description of that ticket.)

What I'm asking for with --no-colors is covering a different use-case: there is a user waiting at the terminal for lychee to do its thing, thus a progress bar is still welcome; however perhaps the user's terminal is "broken", "ancient", or run with a pseudo-TTY inside in some other tool (like an IDE), and thus all the fanciness doesn't work.

Thus my proposal for --no-colors, would just remove the emojis / emoticons, and perhaps switch the other UI related elements to use ASCII only characters for drawing.

Sounds good.
ripgrep supports this through --color, even though I think it wouldn't be as easy to implement.

--color <WHEN>
    This flag controls when to use colors. The default setting is 'auto', which
    means ripgrep will try to guess when to use colors. For example, if ripgrep is
    printing to a terminal, then it will use colors, but if it is redirected to a
    file or a pipe, then it will suppress color output. ripgrep will suppress color
    output in some other circumstances as well. For example, if the TERM
    environment variable is not set or set to 'dumb', then ripgrep will not use
    colors.

    The possible values for this flag are:

        never    Colors will never be used.
        auto     The default. ripgrep tries to be smart.
        always   Colors will always be used regardless of where output is sent.
        ansi     Like 'always', but emits ANSI escapes (even in a Windows console).

    When the --vimgrep flag is given to ripgrep, then the default value for the
    --color flag changes to 'never'.

we don't need syntax highlighting at this moment. So no need for that.

(Also we currently are not able to report the row and column number of a bad URL, so previewing the lines around the bad URL is not feasible.)

Sorry, I rather wanted to point out the automatic environment detection through the TERM environment variable and the check for pipes. This way users would not have to configure lychee with --no-colors and it would just work. Of course, a way to overwrite the behavior should exist as well.
If that sounds like overkill I'm fine with adding --no-colors.

Use TERM to decide whether to use color is not reliable because it can be set wrong. But if we assume it's set correctly as in most cases, we still need terminfo to determine whether it supports colors. See https://docs.rs/terminfo/latest/terminfo/capability/index.html

(Also note that termcap doesn't work for this purpose, because it doesn't include color capability.)

But then if we do want to use terminfo, is that a bit overkill?

Detecting pipe is a good idea but counterintuitive it may not be what you want.

Take Emacs as an example, it often takes the output of an external program not from pipe, but from a temporary file. Also it can display escape sequence so for example cargo-process (an Emacs plugin for cargo) just keeps the colors from cargo.

So I believe we should not turn off color automatically when there's a pipe.