Pasting a list of links creates newlines in between links

So, the bug more generally is that posting -any- series of consecutive lines from a rich text source on Mac into Obsidian inserts newlines.

I realize versions of this have been posted before, and people (generally well-meaning users, NOT anyone official) keep undermining the report by saying “oh, paste without formatting!!”

Well, in this case this won’t work, because I’m trying to paste links.

Specifically, I’m trying to paste a series of tasks from OmniFocus, which paste into Obsidian (and other rich text recipients) as a series of consecutive lines containing a single link each but you can reproduce this just by going into TextEdit.

If, in TextEdit, you type:

link 1
link 2
link 3

…with no newlines, link each to, say, then copy/paste that series of links into Obsidian you get:

[link 1](

[link 2](

[link 3](

…with newlines inappropriately inserted between each item.

That gets in the way pretty heavily of converting them to Obsidian todos and fixing any nesting, since each turns into a one-item list that can’t be (correctly) indented under the one above.

Yes, you can paste without formatting with Cmd-Shift-V, but then you only get a plaintext list that strips all your links. That’s not really reasonable when the idea is to post all the tasks that link back to OmniFocus.

As it stands now you have to laboriously remove each newline (or figure out a regex filtering approach) which is a real PITA when pasting a bunch of tasks from a large project. Alternately, you can paste a broken plaintext version and not have backlinks anymore.

I think what Obsidian is doing is making each line it sees a “paragraph” by isolating them but in this case that’s really not what’s wanted–nor is it necessary when Obsidian already puts in automatic breaks for consecutive lines.

I want a copy/paste that preserves the consecutive lines AND the inline rich formatting, like what happens in every other rich paste target on Mac.

Is there a plugin that can fix this?

Failing that, is it even possible to file a bug against Obsidian that doesn’t get explained away then graveyarded? This one has been posted a number of times.

As a paying user, it’s really painful to watch real issues that affect me daily get raised months or years ago–and then everyone knocking them down like a pinata party until they’re graveyarded. Or worse, they get automatically closed after 3 months, as if that’s enough time for this team to field a bug report. Makes me wonder why I bother paying them.

1 Like

I can’t reproduce this. Copy pasting this in the obsidian sandbox from chrome doesn’t add extra lines for me on windows.


Do you get extra lines if you copy the above from Chrome? what about Safari?
Perhaps, it’s an issue specific to Omini focus because it’s ominifocus that adds the extra lines.

If the content of the HTML clipboard contains the extralines (or a separate paragraph per line), we will have those too.

That is interesting. You’re right, re: pasting from Chrome and Safari. I can also see it’s adding an implicit two spaces to the end of each line except the last (even though Obsidian doesn’t need it) so it’s plainly converting them to consecutive lines intentionally via some kind of HTML->Markdown filter.

I just tried pasting a list of three consecutive text lines from Notes, though, and it added blanks in between. I’m out of time to dig up Mac apps I can type text into to copy/paste, but I’m willing to bet anything but the web browser is likely to show this. You really need to test with a different source.

You say the HTML clipboard. Text coming from a formatted app on Mac (other than from an HTML pane) would be Rich Text source, which I think is a different clipboard item type. You certainly seem to be processing it differently.

I have most of the popular productivity tools (Alfred, Keyboard Maestro, etc) so if you give me a hint how to check what’s literally sitting in the clipboard as a source I’m happy to do so. I’m sure one or more of them has the ability.

But given that OmniFocus pastes as consecutive lines of links in every other rich text target app I’ve tried–and given that even otherwise unformatted Rich Text lines do this–I’m going to say it’s probably not specific to that app, and it’s more that your handling of Rich Text clipboard items isn’t consistent with the rest of the system or your handling of HTML.

We do not handle rich text at all. We only convert the HTML in the clipboard.

You can paste here and see the content of the clipboard

I pretty sure you will see the extra lines or each line is enclosed in paragraph <p> <\p>

1 Like

Yeah, it’s the latter. Each line in the HTML version is enclosed with <p></p>.

Here’s what copy/paste:


…from a Mac rich text source looks like:

So, OK. That explains the phenomenon so at least people searching in the future understand what’s up. That’s an improvement over what I walked into trying to solve this.

This is still really crappy behavior on a Mac, though. HTML is -not- an appropriate interchange format because it imposes its own formatting quirks, and the app using it as one isn’t going to give appropriate results. I get your implementation leads the app in this direction, but I’d still appreciate you understanding that from an end user perspective, this is still a bug and treating it as such.

Maybe there’s some kind of option or additional paste you can add that comes down to “no blank lines between paragraphs.”

NO, html is an excellent interchange format and one has to wonder why some Mac Apps (most likely they all share a library) produce HTML with a paragraph where there isn’t one.

If it’s all the native apps and down to how the operating system automatically converts RTF to HTML on the clipboard, as I kind of suspect it is, it’s not a good interchange format on Mac. Doesn’t matter if you’re “technically” correct or not. Apple isn’t going to change for you.

I wasn’t looking for an argument, though. I just want the app to behave appropriately on my OS. Since HTML interchange under the hood is a completely invisible factor, expecting me to understand and field that for your behavior doesn’t feel appropriate to me.

Again, I ask that you honor this as the end user bug it feels like, and I really don’t want to debate it further whether or not you think you’re “right”. The end behavior is surprising and annoying, and that’s wrong enough.

We can’t change the way our HTML parser works because we have no way of knowing if the HTML in the clipboard was produced by an APP with these added paragraphs on not.

Feel free to open a FR to support RTF in the clipboard.

This is a paste from OmniFocus.

Note the HTML generator is the same (Cocoa HTML Writer) as the paste from Notes. That’s because it’s an standard OS- or framework-level conversion. You can count on every Cocoa app operating the same way. It’s not a per-app thing.

On Mac, RTF is the interchange format. HTML is derivative, and has copy errors.

If that’s “broken” on Mac, so be it, but it’s the broken environment your app supports so I hope you’ll consider some way or option to compensate, as I requested above.


Re: request for direct support of RTF on clipboard, sure, I can do that. It probably is the solution needed since, as mentioned, I do believe that’s Mac’s native format.

Re: not knowing, that is why I suggested an option (I never paste real HTML from a browser) or a different paste command that converted paragraphs to line breaks. I have no idea if that’s doable at a plugin level or if it’d have to be in-app, but it’d work around the Mac behavior.

You can see the generator line, though. Maybe only Cocoa HTML Writer needs this?

1 Like

Per above, I just tried pasting content straight from Safari and it does -not- have the generator line. I think that will only be present for the RTF->HTML conversion.

So you do have a flag as to when to compensate for paragraph breaks. An option for converting <p> to <br/> only for that generator would likely fix this.

…and here’s a paste from Notes with blank lines intentionally added. Note the extra <p><br></p> it adds for each blank line.

I think it’s safe to say with Cocoa HTML Writer, every paragraph is really a single-spaced line for the purposes of converting to Markdown, and the second line break on </p> shouldn’t happen.

1 Like

We would have to do some further tests to make sure that this is the case.
Feel free to open a feature request for that.

1 Like

Makes sense re: testing. I’m definitely making a few educated assumptions there. I’ll post something in FR. I suspect compensating for that generator would be a lot easier than supporting RTF in general though, so I’ll at least post both requests separately.

Is the clipboard something plugins can intercept and change? If so, it might be my impetus for looking at what it takes to make one.

It’d be great to also report the problem to Apple (they do listen to feedback sometimes), but their user feedback page doesn’t have a good place to report this sort of thing. There’s a separate feedback route for developers which is probably the place for it, but I’m not a developer.

I suppose we could report it against Notes and/or other affected apps.

The “converts rich text to markdown” action in Shortcuts has the same problem.

1 Like

Line breaks (CTRL ENTER) from TextEdit, Pages, etc paste as consecutive lines into Obsidian.


Paragraph breaks (ENTER) from TextEdit, Pages, etc paste as discrete paragraphs into Obsidian.




So it depends on what type of break has been used in TextEdit, Pages, etc, yes?

If this is the case, than everything is correct.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.